Assembled by Default

Every organization deploying agentic AI is making a design decision it doesn't know it's making.

Not which model to use or which platform to adopt. Those decisions get months of evaluation, vendor demos, pilots. The design decision that determines outcomes is how the human-agent working unit is structured: who initiates work, who holds context, where reasoning happens, when the human engages, what the configuration preserves and what it optimizes away.

Almost nobody is making this decision deliberately. The configuration is assembled from whatever the platform provides plus whatever habits the engineer brings. An engineer using one agentic platform works in a different configuration than one using another -- different relationship to context, different governance posture, different tradeoff between understanding and throughput. But neither engineer chose their configuration. They chose a tool. The configuration came bundled.

This matters because the same agent capabilities produce different organizational outcomes depending on the design of the configuration. An agent that accelerates delivery within a configuration designed for understanding makes the organization faster and smarter. The same agent within a configuration designed by default makes the organization faster and more fragile. The tool is identical. The configuration is the variable. And right now, the variable is uncontrolled.

This is like building a factory by letting workers arrange their own stations without thinking about workflow, quality control, or how the pieces fit together -- except the factory is producing the decisions your organization runs on.

The configuration is the new unit of organizational design. And it has no designers.

What a Configuration Actually Is

A human-agent configuration is the complete working arrangement: not just the agent, but the human's relationship to it. Who frames the problem. How constraints are defined. Where checkpoints exist. Whether the configuration preserves the moments where assumptions surface or optimizes them away. Whether the human engages continuously, at checkpoints, or only in retrospect.

Two engineers, same codebase, same agent platform. One works in continuous collaboration -- reasoning through the problem, using the agent to accelerate execution of that reasoning. The configuration produces output and understanding. The other delegates: defines a task, hands it off, reviews the result. The output arrives, tests pass, nothing looks wrong. The configuration produces output without understanding.

Both look identical on every delivery metric. The difference is invisible until something breaks and the second engineer can't explain why the system behaves the way it does -- because they never encountered the resistance that would have forced their understanding to develop.

This is not a story about discipline or skill. It's a story about design. The first engineer isn't more careful. They're working within a configuration that preserves reasoning as a byproduct of how it operates. The second engineer's configuration was never designed to do that. It was designed -- by the platform vendor, by default -- to optimize throughput.

Now consider a third engineer, working in the same codebase with the same agent, but within a deliberately designed configuration. The agent is decomposed into specialized roles with explicit scope. One role classifies every change before any code is written: scope, risk level, boundary assessment. A read-only investigation role traces the execution path and surfaces hidden dependencies -- it can't modify anything, only show the engineer what they're about to touch. Implementation roles are scoped to a single architectural boundary -- the agent can only read and write within allowed paths, cannot touch shared infrastructure, cannot cross service boundaries without escalation. A verification role checks against human-defined correctness criteria, not agent-defined criteria.

This engineer didn't choose a different tool. They work within a different configuration of the same tool. The configuration was designed to force boundary-awareness, to require investigation before editing, to separate understanding from implementing. The agent is the same. The configuration is what makes the difference.

Configurations are not just "how people use tools." They encode organizational assumptions about where understanding matters, where speed matters, and how the tradeoff between them should be managed. Every platform ships a default answer to those questions. Most organizations have never examined the answer they're living inside.

Three Governance Assumptions That Are Failing Simultaneously

The governance crisis around agentic AI is usually framed as governance needing to "keep up" with AI. The problem is more structural than that. Existing governance mechanisms encode specific assumptions about how work is done, and three of those assumptions are failing simultaneously.

The first is individual authorship. Code review was designed for human-written code evaluated by a human who could ask "why did you do it this way?" and get a substantive answer. When the author is a configuration -- when the reasoning happened across a human-agent interaction that the reviewer wasn't part of -- that question stops producing useful signal. The reviewer sees plausible output. The output was optimized to look correct. The surface plausibility of agent-generated code activates the same heuristic shortcuts in reviewers that well-written human code does -- except plausibility says nothing about whether the reasoning was sound. The governance mechanism that was supposed to catch errors now triggers pattern-matching rather than critical evaluation: a glance, a plausibility check, an approval.

Performance evaluation faces a parallel problem. When the unit of production is a configuration, the human contribution is in framing, directing, and evaluating -- none of which existing metrics capture.

The second is human-speed change. Change advisory boards, architecture reviews, and release gates operate on governance cycles -- periodic checks, quarterly audits, approval meetings. Configurations produce changes continuously. This is not a speed problem fixable by faster reviews. It's a category mismatch. The governance gate itself must change, not just its cadence. And the organizations that are choosing speed over governance aren't doing it because they don't value governance. They're doing it because the existing mechanisms cannot operate at the cadence configurations produce.

The third is tacit knowledge as safety net. The friction of traditional development processes -- informal peer review, hallway conversations, the senior engineer who says "we tried that in 2011 and here's what happened" -- was the mechanism through which institutional knowledge surfaced and transferred. Configurations absorb that friction. The knowledge transfer stops. The need for that knowledge doesn't. The senior engineers who hold institutional memory are now consumed by correcting and guiding agent behavior -- an institutional knowledge tax that pulls them away from the work their expertise is supposed to enable.

These aren't three separate governance problems. They're one structural failure: governance systems designed for human-only work cannot govern human-agent configurations. The temporal mismatch, the plausibility trap, and the tacit knowledge gap compound into something that can't be addressed by any combination of existing mechanisms, no matter how fast or rigorous you make them. The mechanisms themselves assume a world that configurations have already changed.

Configuration Debt

Technical debt is well understood. You take a shortcut in the code, you accumulate a cost you'll pay later. The concept gives organizations language for a tradeoff they're making, which is the first step toward managing it.

Configuration debt is an analogous cost, but with a crucial difference. Technical debt lives in the artifact -- the code. You can see it, audit it, refactor it. Configuration debt lives in what was never produced. Understanding that was never generated can't be reconstructed after the fact. An assumption that was never articulated can't be audited. A junior engineer who never encountered resistance can't retroactively develop the judgment that resistance would have built.

Technical debt says: we took a shortcut, and we'll pay the cost to fix it later. Configuration debt says: the process by which we work has stopped producing something we need, and we can't go back and produce it retroactively. The debt is in the absence, not in the artifact.

"Process debt" and "organizational debt" already exist as concepts. What configuration debt adds is specificity -- it names the particular mechanisms through which the cost accumulates and ties them to a particular cause: the design of human-agent working units. You can't manage a cost you can't name, and most organizations are accumulating configuration debt without knowing it.

The mechanisms take distinct forms.

Understanding debt is the most intuitive. The configuration produces output the team can't explain. Not wrong output -- working output whose rationale has been lost. Each iteration widens the gap between what the system does and what the team understands about why. This compounds in a way that has no precedent in traditional development: each layer of agent-generated architecture becomes the foundation for the next layer of agent-generated architecture, and the team's understanding of the foundation was never solid to begin with.

Assumption debt is less visible. The configuration encodes assumptions -- about system behavior, about user needs, about operational constraints -- that were never made explicit. Unlike technical debt, which is at least visible in the codebase, assumption debt is invisible because it lives in the configuration's design: in what the agent was told to optimize for and what it was never asked about. You can audit code. You cannot audit assumptions that were never articulated.

Judgment pipeline debt produces no symptoms for years. The configuration works well enough that junior engineers never encounter the resistance that builds deep understanding. Current judgment is adequate. The pipeline for developing future judgment is broken. This form of debt surfaces as a cliff: the engineers who built their judgment through traditional paths leave, and the organization discovers that no one behind them can explain why the system works. Organizations can transition from strong velocity to system incomprehensibility in less than eighteen months.

Governance debt is the most insidious because it wears the clothing of its opposite. Output volume exceeds the organization's capacity to meaningfully review it. Review becomes sampling. Sampling becomes spot-checking. Spot-checking becomes rubber-stamping. The formal governance structures remain -- the reviews happen, the approvals are recorded, the compliance boxes are checked. The substantive governance has hollowed out. The organization feels governed. The governance is performative.

What makes configuration debt dangerous is its irremediability. You can refactor code. You cannot go back and generate the understanding that should have been a byproduct of the work. You cannot retroactively expose junior engineers to the resistance that would have developed their judgment. You can only change the configuration going forward and wait for the new process to produce what the old one didn't.

Meanwhile, the debt compounds. Each poorly-understood decision becomes the foundation for the next set of decisions, and configurations accelerate the rate at which decisions are made. The empirical signature is already visible. Organizations adopting agentic AI see throughput increase while stability decreases. More output, more incidents per unit of output, higher change failure rates. That pattern -- velocity up, comprehension down -- is configuration debt accumulating across the industry. Almost no one has a name for what's happening.

Why You Can't Measure Your Way to Good Configuration Design

The instinct, at this point, is to measure. Find a metric for configuration quality, set a target, track it. This will produce performative configuration design -- the same dynamic that produced hollow agile implementations when organizations measured velocity instead of value. Every countable proxy for reasoning quality will be gamed. Decision logs produced to satisfy a process rather than to advance understanding. Configuration design artifacts that check boxes without changing how work happens.

The reason is structural, not cynical. Configuration quality is a capacity, not an event. Delivery is countable -- features shipped, pull requests merged, cycle time. Capacity resists that kind of accounting. You cannot count the quality of a problem framing. You cannot measure the value of an assumption surfaced early except by the absence of a crisis that never happened.

This is Goodhart's Law: when a measure of configuration quality becomes a target, it ceases to be a good measure of configuration quality. Direct measurement doesn't just fail to capture what matters -- it actively distorts the behavior it's trying to evaluate.

What you can do is watch for the symptoms of configuration health, or its erosion.

Are code reviews engaging with why an approach was chosen, or rubber-stamping plausible output? Can engineers predict system behavior before investigating, or are they routinely surprised by what their own systems do? Is time being spent on problem framing before directing agents, or is framing being skipped in favor of speed? Are new team members contributing output quickly but unable to explain why the system is designed the way it is?

These are cultural indicators, not dashboard metrics. They require managers who observe directly rather than managing through reports.

There's a concrete heuristic worth trying. Pick a change the team shipped three weeks ago. Ask the engineer who directed the work to reconstruct the reasoning -- not the code, but the decisions. Why this approach? What alternatives were considered? What assumptions is this resting on? If they can, the configuration preserved understanding. If the reasoning happened inside the agent's part of the configuration and was never externalized, the configuration is accumulating understanding debt. Three weeks is long enough for working memory to fade and short enough for the reasoning to still be recoverable if it was ever explicit. The gap between "I can explain this" and "I'd have to re-investigate" is a direct signal.

There's also a lagging indicator. When something breaks, how long does it take to understand why -- not just to fix it? A rollback is a fix. Understanding the failure is comprehension. The gap between mean-time-to-recovery and mean-time-to-comprehension is a direct measure of accumulated configuration debt. Organizations that can recover quickly but take days to understand what actually went wrong have systems that outpaced the team's understanding of them. That gap is honest precisely because it can't be gamed. You either understand the system or you don't, and the production incident makes the difference visible.

You can't measure your way to good configuration design. This is the same lesson from every previous organizational transformation. The answer was never better metrics. It was designing the conditions under which quality emerges as a structural property of how work happens.

Which raises the question: what does that look like for configurations?

Designing the Configuration: Lessons from Manufacturing

The richest precedent is manufacturing -- but not the version most people think of. The popular understanding of the Toyota Production System is that it's a metrics-driven engineering system: lean processes, waste elimination, measurable quality. The deeper reading, the one Deming scholars emphasize, is that TPS was fundamentally a culture. Any worker on the line could stop production when they encountered uncertainty -- not because they could always see the defect, but because the organization created the conditions where stopping was the expected response. Psychological safety, process authority, management commitment. Quality was a property of how people worked, not something inspected into the product after the fact.

This distinction matters. If Toyota's system were really about metrics, it would be a poor analogy for a problem that resists measurement. But Toyota's actual insight is about designing cultural conditions into the production process -- which is what configuration design requires.

The analogy has limits. Manufacturing has known tolerances. A dimensional defect in a car part can be detected because the specification defines what "correct" looks like. Software development operates under genuine uncertainty -- you often don't know what the right assumption looks like until production proves you wrong. The specific mechanisms are suggestive, not directly portable. But the principle is the part that matters.

Toyota's machines were designed to stop themselves when they detected an abnormality rather than producing defective output faster. The configuration design equivalent: agent workflows that surface uncertainty rather than resolving it silently. A classification step that forces scope assessment, risk-level determination, and boundary analysis before a single line of implementation begins. Tiered autonomy zones where some areas of the system allow no agent modification at all, others allow agent proposals that humans implement, and others allow constrained agent execution. The configuration stops itself when the work crosses a boundary that demands human judgment.

The human equivalent is not approval gates -- those become governance theater at scale. It's structural checkpoints where the engineer must engage with what the configuration is producing before it moves forward. The read-only investigation role described earlier does this: when it reveals that a "single-service change" involves event consumers in three other services, the workflow escalates. The engineer names the boundary crossing before it happens. The line stops. It's supposed to.

Process improvement was treated as a continuous practice, not a periodic review. Configuration design works the same way -- it's not a one-time architectural decision. Not retrospectives that ask "what did we build?" but retrospectives that ask "how did we build it, and did the way we worked produce understanding alongside output?" Comparing the assumptions made at the start of work with the behavior observed after release, and feeding those lessons back into how future work is framed.

And at every level, direct observation replaced reporting. You cannot evaluate whether your configurations are producing understanding by reading a report about whether your configurations are producing understanding.

The honest limitation of the analogy is that manufacturing tolerances are defined by the material. Software tolerances are defined by the designer. But that difference strengthens rather than undermines the discipline. Architectural boundaries, ownership boundaries, risk tiers -- these can be specified by the configuration designer even though they're not inherent in the material. The discipline is defining them explicitly and building the configuration so that it respects them structurally, rather than relying on individual engineers to remember them under pressure.

One qualification. Not all configurations need to produce understanding. A routine dependency upgrade in a well-understood system can optimize for throughput. A migration touching cross-service contracts cannot. Toyota didn't apply the same scrutiny to every component -- it applied appropriate scrutiny based on criticality. "Risk determines rigor" is the configuration equivalent. The problem isn't that some organizations optimize for speed. It's that all configurations optimize for speed by default, because that's what platform defaults produce and incentive structures reward, regardless of whether the specific task warrants it. The design discipline is about making the tradeoff intentional.

A skeptic might ask whether configuration design is just good engineering management with new vocabulary. The answer is that the specific design parameters didn't exist before agentic AI. Read and write scope decomposition -- what the agent can read versus write versus never touch -- is not "set clear expectations and coach your team." Read-only investigation roles that force understanding before implementation didn't exist when the implementer was always human. Boundary-crossing escalation triggers -- governance embedded in the working unit rather than applied after the fact. Tiered autonomy graded by consequence of error. The structural separation of correctness-definition from implementation -- the human defines what "correct" means, the agent implements toward it, not the reverse. These are design parameters of a working unit that didn't exist before, and a manager who designed excellent human-only processes won't automatically design excellent human-agent configurations, because the failure modes and design levers are different.

One more complication worth naming. Agents are increasingly participating in designing their own configurations. Some agents ask permission before destructive actions. Others request review at uncertainty thresholds. The trajectory is toward configurations that co-design themselves. This doesn't remove the human responsibility -- it moves it up a level of abstraction, from "how should I work with this agent?" to "is the way this agent and I have arranged our collaboration actually producing what the organization needs?" Configuration design becomes recursive. The bar for human judgment rises.

And there is an open frontier the discipline has barely begun to address. The design principles described here work best for human-in-the-loop configurations, where the human sequences every step. Many configurations are moving toward human-on-the-loop (monitoring rather than directing) or human-over-the-loop (setting objectives and evaluating outcomes). How you preserve understanding in those configurations -- where the human isn't present for the moments where assumptions are made and reasoning happens -- is a genuinely unsolved problem.

But the question is deeper than mechanism. Each step along that spectrum is a decision about what role human understanding plays in the organization -- whether understanding is instrumental (something you need to catch errors and govern effectively) or constitutive (something the organization is). If understanding is instrumental, then on-the-loop and over-the-loop configurations need alternative mechanisms for producing it. If understanding is constitutive, then the design question isn't how to preserve understanding at a distance. It's what kind of organization you become when understanding is no longer a structural part of how work happens.

The configuration doesn't just shape workflow. It shapes the ecology of thought the organization can sustain -- what kinds of understanding are possible given how humans and agents relate to each other. Move the human far enough from the work and you haven't optimized a process. You've changed what the organization is capable of knowing about itself.

An organization that can no longer reason about its own systems can still operate them -- until it can't. And it will have no way of seeing the difference until the moment arrives.

Naming this matters more than pretending to solve it. The organizations grappling with the question honestly are further ahead than the ones that haven't noticed it exists.

How Configuration Design Takes Hold

If configuration design can't be incentivized through direct measurement without distortion, how does it take hold? The same way any organizational capacity takes hold: by creating conditions where good design is the path of least resistance to outcomes the organization already rewards.

Incident analysis is the strongest lever. When production incidents occur, trace them not just to code-level causes but to configuration-level causes. Was the failure rooted in an assumption the configuration never surfaced? A constraint that was never defined? An understanding gap the configuration's design could have prevented? If incidents regularly trace back to configuration quality, the incentive to design well becomes self-reinforcing without anyone counting artifacts. The organization learns that configuration design matters not because a policy says so, but because the consequences of its absence are visible.

Evaluation shifts from output to comprehensibility. Promotion criteria that reward the ability to explain your system, trace decisions to rationale, and demonstrate that your configurations produced understanding alongside output. The engineer who can articulate why their system works -- not just that it works -- has provided evidence no throughput metric can capture. This requires managers who can evaluate these qualities, which is its own constraint. You can't evaluate configuration quality from a dashboard. Assessing configuration design is itself a capacity that has to be built.

The early research on human-machine teaming -- from chess to medical diagnosis -- suggests that the synergy skill is not domain mastery but the ability to structure the collaboration itself. That finding is suggestive, not prescriptive. Tool fluency without technical depth produces faster bad decisions. Configuration design requires the traditional skills -- system thinking, architectural judgment, critical evaluation -- operating at a higher level of abstraction. But it does challenge the assumption that the right response to agentic AI is simply hiring the strongest individual contributors and giving them agents.

The counterintuitive implication: the best junior engineers in an AI-native world may be the ones slower to accept agent output. Speed of acceptance signals shallow engagement. The hire you want is the one who says "I don't understand why this works" before shipping it -- because that question is the one the configuration should have forced them to ask.

There is a scalability problem here. The most successful designed configurations come from experienced practitioners with deep system understanding -- engineers who know the architecture's risk surfaces, the organizational boundaries, and who can decompose the agent's work into the right roles. That works when one leader designs the configuration for one team. It doesn't scale to dozens of teams where no single person holds that understanding. The answer is the same one that emerges from every attempt to scale organizational capacity: culture. You can't write a configuration template for every system. You need engineers who can design their own -- which requires the kind of judgment that develops through practice, not through policy. The discipline scales through shared practice, not through prescription.

The Discipline That Doesn't Exist Yet

Configuration design is the discipline that doesn't exist yet. The concept of human-agent configurations is entering the discourse. The idea that they should be designed intentionally has not.

A well-designed configuration is the concrete mechanism through which a reasoning culture operates. A configuration assembled by default is where culture's governance fails, regardless of what the org chart says or the governance framework promises. The configuration is where the organization's values either shape how work happens or don't.

The behavioral patterns forming now -- whether engineers question agent output or accept it, whether they frame problems before directing agents or skip framing in favor of speed, whether they treat the pull request as sufficient governance or demand understanding alongside output -- are becoming culture. The patterns are self-reinforcing. Organizations that question agent output develop engineers who question agent output. Organizations that accept it develop engineers who accept it. Each cycle deepens the pattern. You can switch tools in a day. You can't switch from a culture of passive acceptance to a culture of active engagement in a day.

By recent estimates, roughly 6% of organizations are designing their configurations intentionally. The rest are letting behavioral patterns solidify into "how we use AI here." The difference between a design problem and a culture change problem is an order of magnitude of difficulty -- and the transition between them is already underway.

Every undesigned configuration is still a design. It's just one that a platform vendor made, optimized for adoption rather than understanding, producing an organization that gets faster without getting smarter. The question isn't whether your configurations are shaping your organization. They already are. The question is whether anyone chose the shape.