The main body develops the argument in sequence: execution becomes orchestration; AI changes both throughput and exploration; human attention and context become scarce; customer signal, not a specification handed over the wall, is where the lifecycle starts; the developer platform becomes the orchestration platform; organizational knowledge moves into runtime; paved roads become accessible to agents; support latency, security, cost, evaluation, and organizational learning become platform concerns; and enterprise products participate in agentic workflows.

The chapters trace one software development lifecycle (SDLC) loop, and about half of them are stages in it while the other half are the concerns that apply at every stage. The loop runs: discovery (customer signal becomes a specification), intent and planning, implementation and testing, review and decision, delivery, and operation and learning — with learning returning to discovery rather than to a backlog.

The map below says where each chapter sits, so a reader can enter at the stage they care about instead of reading in sequence. In the printed order these group into six parts — the operating model, what the platform provides, constraints and consequences, the organization and what it sells, how the work runs in practice, and work with no human trigger — each announced with a short preamble as you reach it.

The appendices contain elaboration, evidence, metrics, citations, background reading, and the topics that recur across any enterprise AI-native platform review and still need enterprise-specific resolution. Those topics appear as provisional positions and explicit decision questions rather than unsupported conclusions.

Movement between tiers requires measured performance against the evaluation harness and an explicit authorization from the Autonomy Council (see below). Tier assignment is per capability, not per agent.

References are numbered R1 through R283 (with ambient-agent additions R284+) and consolidated in Appendix P. Cross-references between chapters use the short form Glossary.

Every acronym the document uses more than in passing, in one place, so a reader who meets one mid-chapter does not have to hunt for where it was introduced. Terms with a conceptual definition have a full entry above; this table is for lookup.

This document borrows working vocabulary from several external traditions. Terms are attributed here so a reader can trace them back to their canonical source and read further. Where a term was coined by an identifiable author or publication, that source is cited inline. Where a term is documentary convention (T0, decision packet, ambient agent as used this way) originated by this document, that is noted as well.

Reading further. Fowler’s bliki (https://martinfowler.com/bliki/) and the Thoughtworks Technology Radar are the single densest sources for the software-engineering vocabulary this document builds on. The Google SRE Book and SRE Workbook (free online at https://sre.google/books/) supply the operational vocabulary. Accelerate supplies the delivery-metric vocabulary. The MCP and A2A specifications supply the interoperability vocabulary (Appendix D, Appendix M).

The normal mode is delegation, not supervision. An engineer states an outcome, hands over bounded work, and goes to do something else while agents build, test, inspect, and gather evidence. Nobody sits watching an agent type.

The loop is: delegate, execute, accumulate evidence, return a decision or an exception, judge, resume. Concurrency comes from the engineer not being inside each execution — which is what makes several tasks in flight a normal Tuesday rather than an act of heroism.

Interactivity is the escalation path, not the default. It earns its place when a UI needs to be felt rather than described, when a root cause will not resolve from a trace, when the agent cannot settle an ambiguity, or when an engineer wants to watch the exact failing runtime. Then the loop becomes delegate, observe, inspect, intervene, resume.

An engineer can descend from a decision packet to logs and traces, to a shell, to a running preview, to a debugger attached to the live process, and back out again. This is not a concession. A senior engineer will reject a platform that puts them one layer above the system and offers no way down, and they will be right to — the debt chapter names what a platform costs the organisation when understanding stops being available on demand.

A running work context can be handed to another person under differentiated access: a live preview for a designer, acceptance evidence for a product manager, a shell and debugger for an engineer, policy findings for a security reviewer. Colleagues collaborate on the running artifact rather than on a description of it, often before a pull request exists.

A workspace is a logical package of work context, not a process. It can be suspended, resumed a week later, handed to a colleague, or reconstituted somewhere else without the work being reconstructed from memory. Identity, secrets, and privileged data access are re-brokered at each boundary rather than travelling with it.

Linux containers, Windows and macOS workers, emulators, simulators, physical-device pools, and the engineer’s own laptop are all legitimate substrates. Build tooling for Apple platforms needs macOS; a tight UI loop often wants the machine on the desk; a thousand-service sweep wants managed infrastructure.

Where a task runs is a scheduling decision made from toolchain, data classification, residency, latency, hardware, and cost — not a fact the engineer has to hold in their head. The workspace broker is a placement engine as much as a security boundary, and reserving a scarce macOS executor while an agent reads source is a waste it should refuse to make.

A workspace is the logical package of work context; the substrate is where it happens to run. The broker chooses placement from toolchain, data classification, residency, latency, hardware, and cost — an Apple toolchain needs macOS, a tight UI loop often wants the machine on the desk, and a fleet-wide sweep wants managed infrastructure. The dashed return is the property that matters most: the workspace outlives any single execution, so it can be suspended, resumed, handed to a colleague, or reconstituted somewhere else. Identity, secrets, and privileged data access are re-brokered at each boundary rather than travelling with it.

Backend work proves itself with contracts and integration tests; UI work with visual diffs, accessibility checks, and a device matrix; data and machine-learning work with provenance and drift; security work with policy and supply-chain evidence; operations with canary health and rollback. Autonomy ceilings follow the strength of the available evidence, which is why some classes of work will sit at a lower tier for a long time.

An agent receives bounded capabilities rather than credentials, under an identity, a delegated authority, a scope, an expiry, an audit trail, and a revocation path. The model proposes; independent infrastructure constrains, records, and can stop the action.

The platform exists to concentrate attention on the decisions that need it, not to maximise autonomous activity. Every principle above is in service of that one.

The adoption argument follows from the list rather than from a claim about speed. An engineer working this way delegates the boring half, runs more work at once, is interrupted when their judgment is worth something, can see everything, can take the controls, can hand a live problem to an expert, and does not rebuild the same understanding of the same system every week.

The solid path is the normal one. The dashed path is the escape hatch: available, deliberate, and not where the engineer spends most of their day.

Viewpoint

The most economical description of the change is that engineers move from execution toward orchestration. Today, engineers still spend much of their day translating intent into code, running tools, waiting on builds, diagnosing failures, and coordinating handoffs. As agents become more capable, an engineer can state a goal, delegate work, inspect intermediate results, redirect the work, and decide whether the outcome is acceptable.

This is not a claim that coding disappears or that engineers can become detached from the systems they own. The risk runs in the opposite direction: if the machine performs the work, the engineer may be less immersed in the details at precisely the moment a consequential decision is needed. The platform must compensate by preserving evidence, intent, changes, and unresolved questions.

Concrete proposal Create an orchestration platform that accepts outcomes and constraints, decomposes work into bounded tasks, assigns agent workspaces, records intermediate evidence, and returns consequential decisions to an accountable engineer.

Business driver and expected gain Agent execution lowers the cost of routine implementation and tool work. The business opportunity is to increase delivery capacity without making engineers the manual orchestration platform for every agent action.

Organizational requirements Product and platform teams must define task classes, ownership, approval boundaries, and evidence requirements. Engineering managers must protect time for reviewing agent outcomes and maintain clear accountability for services.

Cost and investment Primary investment falls in orchestration services, isolated execution capacity, integrations, evaluation, and developer training. Compute cost rises with concurrency, while coordination and routine implementation effort should fall.

Risks and safeguards Engineers can lose system understanding, agents can create excessive work in motion, and ambiguous ownership can hide behind automation. Bound task scope, preserve execution traces, cap concurrency, and keep humans responsible for production consequences.

Relationship to the wider plan This role change establishes the need for orchestration, bounded authority, a decision inbox, and better context delivery. Every later platform capability exists to help engineers direct work while retaining understanding and accountability.

Supporting material Current agent products demonstrate parallel, scoped execution in configured environments, while industry research warns that AI amplifies the surrounding delivery system — DORA, the DevOps Research and Assessment programme, is the source cited most often in this document. See [R1, R7, R8, R11].

This chapter and the ones after it implement the invariants set out in the ten principles.

Viewpoint

Concurrency has two different meanings, and the distinction matters. The first is straightforward throughput: select ten well-scoped defects and let ten isolated workers address them concurrently. That compresses a queue of known work. It is useful, but it is not the whole change.

The second is exploration. A designer or product team can ask for three genuinely different treatments and test them in parallel. An architect can ask for two implementation techniques, build enough of each to expose the difficult parts, and compare them with evidence. An infrastructure idea that previously seemed too expensive to try may become a proof of concept completed in hours rather than months.

This creates cheap optionality: the organization can learn through working alternatives before committing. The value is not the extra code. Much of that code should be discarded. The value is reducing the cost of finding out which direction is promising.

Concrete proposal Offer two explicit workflow modes: production work for bounded, outcome-oriented delivery and exploration work for parallel prototypes evaluated against a stated decision hypothesis.

Business driver and expected gain The return comes from two sources: more known work can proceed concurrently, and teams can afford to test alternatives before making expensive commitments. The second source improves decision quality rather than merely increasing output.

Organizational requirements Teams need lightweight experiment templates, decision owners, evaluation criteria, time limits, and rules for discarding losing branches. Portfolio governance should fund learning rather than reward the volume of generated code.

Cost and investment Exploration consumes additional model tokens, environments, test execution, and reviewer time. Budgets should be tied to the value and reversibility of the decision, with cheaper models and smaller prototypes used first.

Risks and safeguards Teams may create polished alternatives with no decision process, overwhelm review queues, or allow experiments to leak into production. Require an explicit question, comparison method, expiry date, and promotion gate.

Relationship to the wider plan Exploration depends on cheap agent workspaces, reusable paved roads (internal SDKs, service templates, and support pathways the organization treats as the default way to build a class of system), explicit evaluation criteria, and disciplined disposal of losing options. It therefore connects orchestration, testing, cost controls, and organizational learning.

Supporting material Agent systems already support parallel scoped tasks. DORA provides a useful boundary: faster local work only improves outcomes when the broader delivery system can absorb it. See [R1–R3, R7, R8].

Viewpoint

Traditional cycle-time analysis often separates active development from the time a pull request waits. The coding period usually involved direct attention. Once the PR was raised, ownership became ambiguous: several people might be requested, nobody might accept responsibility, and the senior person everyone wanted could be in meetings. Engineers are not continuously polling every review queue, so delays accumulate invisibly.

AI increases the number of items that can reach those queues. Background execution time is not necessarily a problem when the human can do something else. Waiting becomes a problem when agents repeatedly need a person to answer a question, interpret a failed test, approve a change, resolve a policy exception, or review work produced without the person’s participation.

That is why human attention and context reconstruction become the scarce resources. The concurrency ceiling is not how many agents can run. It is how many high-quality interventions the organization can supply without exhausting people or degrading judgment.

Implications

This is one of the document’s most differentiated propositions. External research on queues, review latency, and AI-assisted delivery supports the premises, but the architectural conclusion remains a synthesis rather than a generic productivity claim.

Concrete proposal Instrument the entire delivery flow so agent execution, system waiting, human decision waiting, and context reconstruction are visible separately. Optimize the longest constraint rather than the fastest local task.

Business driver and expected gain More generated work creates little value if it waits for ownership, review, clarification, or recovery of lost context. Reducing human wait and reconstruction time becomes a direct lever on cycle time and developer capacity.

Organizational requirements Platform engineering, developer experience, and delivery leaders need shared flow metrics and service-level expectations for review, escalation, ownership routing, and decision aging.

Cost and investment The work requires event integration across source control, CI, ticketing, review, deployment, and support systems plus analytics and process change. Most cost is organizational integration rather than model inference.

Risks and safeguards Poorly chosen metrics can reward shallow throughput, pressure reviewers, or conceal quality loss. Pair speed measures with verified outcomes, escaped defects, rollback, rework, and developer cognitive load.

Relationship to the wider plan This bottleneck motivates the decision inbox, AI-first review, organizational knowledge at runtime, intelligent routing, and metrics that separate agent execution time from human decision delay.

Supporting material DORA’s research supports treating AI as an amplifier of the surrounding sociotechnical system and reports tensions between perceived productivity, verification effort, throughput, and stability. See [R1–R3].

Viewpoint

A developer orchestrator can begin by organizing pull requests a developer created, was assigned, is watching, or needs to review. In an agentic lifecycle, the unit becomes a decision request: a test does not build; the task is ambiguous; two approaches have different risks; an approval is required; or a production signal contradicts the plan.

A future developer experience could therefore resemble a command center or work inbox. Many concurrent processes continue in the background. The human is called only where judgment is needed, and the request arrives with enough context to make a quick, confident decision. This is different from aggregating notifications. It requires prioritization, ownership, evidence, and a resumable workflow.

Developer orchestrator. Concurrent workflows are filtered into prioritized, evidence-rich decisions and then resumed.

Concrete proposal Build a common decision packet and an inbox that prioritizes by risk, urgency, age, customer impact, and ownership. Each request should arrive with the question, context, evidence, options, and recommended next action.

Business driver and expected gain Concurrency produces more exceptions and approval requests than people can continuously poll. A prioritized, owned decision queue can shorten waiting time while reducing interruption and context switching.

Organizational requirements Teams must define decision ownership, escalation paths, interruption policies, and expected response windows. Product design must treat attention management and context quality as core developer experience concerns.

Cost and investment Investment includes a normalized decision schema, integrations, prioritization logic, notifications, user experience, and instrumentation. The operational cost comes from generating and refreshing decision packets.

Risks and safeguards The inbox can become another noisy queue, recommendations can anchor judgment, and stale summaries can mislead. Deduplicate requests, show provenance and uncertainty, support deferral, and measure whether packets reduce decision time.

Relationship to the wider plan The inbox is the human surface over orchestration. It receives evidence from coding, testing, security, CI, support, and operations, and it applies the same ownership and escalation model across the lifecycle.

Supporting material Multi-agent command-center products demonstrate the supervision pattern, but the durable decision packet and required context packet are architectural proposals in this document. See [R8] and Appendix A1.

Viewpoint

The first reviewer should increasingly be AI. Before a human sees a pull request, an automated reviewer can check obvious defects, organization-specific rules, tests, security patterns, and presentation quality; it can also propose fixes and iterate with the coding agent. That should reduce the number of mechanical issues consuming human attention.

Human review remains important because software is not merely a set of locally correct edits. A person may need to judge intent, architecture, maintainability, operational behavior, security boundaries, and whether the evidence is enough. The review needs an owner, not a broadcast request to a group in which everyone assumes somebody else will respond.

Concrete proposal Place automated review before human review, resolve mechanical findings where confidence is high, and assign every consequential review to a named owner with architecture, security, test, and operational evidence attached.

Business driver and expected gain AI-generated change volume can overwhelm scarce reviewers. Automated pre-review can remove mechanical issues before a person spends attention, while explicit ownership prevents requests from aging in an unowned queue.

Organizational requirements Code owners, platform teams, and security must agree on review policy, severity, suppression, escalation, and evaluation datasets. Senior expertise should focus on high-risk changes rather than reviewing everything.

Cost and investment Costs include review inference, replayable evaluation corpora, CI integration, policy maintenance, and human labeling. Savings come from fewer low-value comments, faster first review, and less rework.

Risks and safeguards Automated review can create noise, false confidence, duplicated findings, or pressure to accept unsafe fixes. Measure precision and recall on known defects, preserve human override, and prohibit autonomous approval outside proven low-risk classes.

Relationship to the wider plan Review consumes organizational standards, test evidence, security findings, and change history. Consequential judgments return through the decision inbox and feed evaluation data about review precision and missed defects.

Supporting material The proposed division of labor aligns with current agent workflow capabilities and with research emphasizing verification and system-level delivery outcomes. See [R1–R3, R7, R11].

Viewpoint

Parallel agentic testing. Specialist test agents converge their results into one evidence bundle, escalating exceptions for human review.

Testing should not wait until a coding agent declares the feature complete. As the implementation agent builds, a testing agent can work in parallel from the same intent and acceptance criteria. That separation matters: the testing agent should challenge assumptions, identify boundaries and failure modes, and create evidence against which the implementation is judged rather than merely encode the implementation it sees.

Concrete proposal Run a testing agent from the same outcome contract as implementation, generate boundary and component evidence independently, select impacted suites cautiously, and permit test healing only under strict invariant checks.

Business driver and expected gain Generated code can outpace manual test creation and maintenance. Independent test generation and targeted execution can shorten feedback while preserving evidence that the implementation meets acceptance, compatibility, and risk requirements.

Organizational requirements Quality engineering, service teams, and platform owners must define acceptance traceability, mandatory suites, flake policy, contract ownership, synthetic-data rules, and approval for changed baselines.

Cost and investment Investment includes ephemeral environments, test data generation, additional model work, test-impact analysis, browser execution, and maintenance of evaluation corpora. Selective execution can offset part of that cost.

Risks and safeguards Agents may mirror implementation errors, weaken assertions, delete coverage, approve visual drift, or miss dependencies. Separate test and implementation reasoning, retain periodic full suites, and block silent changes to assertions and baselines.

Relationship to the wider plan Testing runs beside implementation, feeds review and CI, constrains self-healing, supports deployment decisions, and supplies evaluation data for agent workflows. Production failures should become future regression cases.

Supporting material Testcontainers supports realistic short-lived dependencies, Pact supports consumer-driven contracts, and Playwright documents planner, generator, and healer agents. These tools demonstrate mechanisms, not automatic test quality. See [R25–R28].

Viewpoint

Agentic operations inner loop. Telemetry drives diagnosis, bounded remediation, recovery verification, evidence capture, and continuous improvement.

Operations is not the final handoff after software is built. It is a continuous engineering loop in which production evidence changes what the organization deploys, tests, designs, and prioritizes. With governed access to source, topology, deployment history, observability, incident systems, security findings, runbooks, configuration, and infrastructure actions, agents can assess change risk, detect weak signals earlier, investigate issues, test competing explanations, recommend or perform bounded remediation, verify recovery, and turn the outcome into new tests and platform knowledge. Human accountability remains explicit, especially where an action changes customer traffic, data, regional posture, or security state.

Concrete proposal Build an operations capability in stages: continuous system review and change-risk assessment; conversational investigation and evidence assembly; recommendations with predicted impact; approval-gated runbook execution; and bounded autonomous remediation for proven, reversible actions. Keep probabilistic reasoning separate from a deterministic actuation control plane that enforces identity, scope, preconditions, rollback, verification, rate limits, and emergency stop.

Business driver and expected gain The gain is not only lower incident toil. Earlier detection reduces customer impact; stronger change assessment prevents incidents; progressive deployment limits blast radius; faster investigation reduces time to understand; safe automatic remediation reduces time to restore; and continuous resilience review finds zone, region, dependency, capacity, and security shortfalls before a real event exposes them.

Organizational requirements SRE, service owners, platform engineering, security, release engineering, and incident management must jointly own service health models, SLOs, dependency and topology data, action catalogs, authority tiers, escalation, rollback, verification, game days, and the continuing role of the incident commander. Every production action needs a named owner and an evidence-retention policy.

Cost and investment Investment includes reliable telemetry and topology, service ownership data, deploy and incident integrations, executable runbooks, isolated operational tooling, an actuation control plane, resilience environments, fault-injection capacity, evaluation using past incidents, and around-the-clock ownership. Multi-zone and multi-region validation also consumes real infrastructure and specialist engineering time; AI can reduce analysis effort but does not remove redundancy cost.

Risks and safeguards False root-cause claims, malicious log content, correlated failure, and unsafe fleet-wide action can increase incident impact. Preserve hypotheses as hypotheses, require preflight and post-action checks, use cohorts and canaries, and support immediate downgrade or stop.

Relationship to the wider plan Operations closes the lifecycle loop. Telemetry, incidents, rollback outcomes, and runbooks become context for future development, testing, risk assessment, support, and orchestration policy.

Supporting material Datadog documents AI-assisted investigation; Google sources describe canary deployment, change controls, and graduated operational autonomy. Splunk documents natural-language assistance for operational queries. See [R20–R24].

Metrics tied to this chapter (definitions consolidated in Appendix T):

The Autonomy Council reviews these six numbers per quarter, paired with the debt-trajectory metrics from the debt chapter.

The matrix describes a destination and says nothing about the thing an organisation is standing on. That thing is usually a complete lifecycle already — it just runs on people as the connective tissue.

Today a CVE lands and somebody reads the advisory, somebody else works out which services are exposed, a third person opens the tickets, an engineer per repository makes the change, CI runs, a reviewer looks, release goes out, and someone watches the dashboards. Every arrow in that sentence is a human carrying context from one tool to the next, and most of the elapsed time is in the arrows rather than the steps.

The assisted version, which most organisations now have, speeds up the steps. An engineer drafts the patch faster, writes the ticket faster, summarises the advisory faster. The arrows are untouched, which is why the aggregate improvement is so much smaller than the per-step improvement, and why the measured results are so much weaker than the felt ones.

What this document proposes changes the arrows. A durable work object carries the intent, the evidence and the decisions between stages, so the context does not have to be rebuilt by a person at each hop. That is the whole delta, and it is worth naming plainly because it sets what to look for when assessing a platform: not whether agents can do the steps — they can — but whether anything carries state across them.

The practical first move follows. Before scoring a single matrix cell, map the lifecycle you run today and mark every arrow a person is currently being paid to be. Those are the candidates, and they are usually not where the enthusiasm is.

Viewpoint

The matrix is the platform’s shared vocabulary for scoping any agent capability. A team saying "we’ve automated CVE bumps" is naming row 1, columns 3–7 in green. A team saying "we’ve begun agent-executed complex features with review" is naming row 3, middle columns in blue. The vocabulary makes ambitions and progress commensurable — nobody has to argue about whether their level of automation is "the same" as another team’s.

The rows, from simplest to hardest:

The columns are the SDLC phases the change moves through, from trigger (CVE alert, bug report, feature spec, incident postmortem) through plan, implement, test, review, deploy, and validate in production. A cell is one (complexity, phase) pair.

The matrix begins at the trigger, which means the work that produces a feature spec sits outside it — upstream of column one, on its own shorter ladder. the requirements and discovery chapter covers that half. Reading the two together matters for one reason: a matrix cell can reach a high tier while the specifications feeding it arrive unevidenced, and the tier map will look healthy the whole time.

Concrete proposal Score every proposed agent capability against the matrix before funding it. The score is (a) which cells it touches, (b) what autonomy tier it delivers in each cell, and (c) which platform prerequisites (MCP surface, skill, gateway policy, workspace class) it depends on. The score becomes the capability’s public identity in the internal-platform roadmap and Autonomy Council decisions.

Business driver and expected gain Multiple empirical studies of open-source and enterprise commit distributions place the routine slice — small corrective changes plus simple adaptive changes plus mechanical sweeps — in the 70–85% range of engineering activity. See Appendix P for the sourcing (R3, R346, R353, and the commit-taxonomy line starting at R365). This document treats the 80/20 mark as directional rather than as a pinned constant — the exact number varies by organisation, team, and codebase — but the shape of the opportunity is consistent across studies: the largest single lever is the top rows of the matrix, not the bottom.

Investing in the top three rows first, and in the leftmost columns of the bottom three rows, yields the highest ratio of verified outcomes delivered to scarce human attention consumed. That is the meter the platform is measured on (the trust and governance chapter).

Organizational requirements The Autonomy Council owns the matrix. Every quarter it publishes the current tier map — which cell is at which autonomy tier, what evidence supported the last movement, and what will need to be true to move the next cell. The tier map is public inside the engineering organisation and is a first-order input to platform roadmap decisions.

How we measure this Metrics tied to this section (definitions consolidated in Appendix T):

Four panels showing what an accountable engineer’s day looks like as the matrix fills in. Today, most work is local — the engineer juggles a couple of tasks on a laptop. Twelve months on, a few routine tasks run against ephemeral compute in the background. Eighteen to twenty-four months on, the engineer’s primary interface is the decision inbox and a dashboard of agent tasks. In the target state, spec-to-deployment for the routine and mechanical bands runs mostly hands-off; the engineer intervenes on the consequential decisions.

Viewpoint

The value of the matrix is not the picture at any single moment. It is that the picture changes. The platform’s job is to move cells rightward and downward over time as three things mature together: the MCP surfaces that let agents access enterprise systems (the foundations chapter), the A2A coordination that lets specialist agents cooperate under one decision packet, and the decision-inbox / autonomy-council governance that keeps human attention sharp on the consequential slice.

Two dynamics deserve to be named explicitly:

Auto-approval at the trivial band. At row 1 (CVE / library bump), the platform should not merely execute the change and notify a human — it should be able to auto-merge under evidence when the evidence is dispositive. The evidence includes vendor security advisories, the diff scope, tests before/after, CI green, no runtime signal degradation in canary, and a comprehension record that names the risk class. Auto-approval is not an abdication of human accountability — the Autonomy Council chartered the policy, and the auto-merged changes are still visible in the comprehension record and debt-delta accounting. It is a recognition that requiring a human keystroke on a change with overwhelming positive evidence destroys the value the platform was built to deliver.

The far target is a wish, and useful anyway. No one shipping today can plan and execute a large multi-service feature, with UI, spec-to-deployment, with minimum human interaction. Multiple prerequisites are unsolved — see the open question on multi-service testing later in this Part. But naming the target state matters because it disciplines every intermediate investment. Every capability shipped should be justified in terms of how much closer it moves the platform to that state, and how much of the 80/20 slice it captures on the way.

Concrete proposal Publish a twelve-month journey plan alongside the tier map. The journey plan states which cells the platform intends to advance, in what order, and what evidence will be considered dispositive for each advancement. The plan is public inside the engineering organisation and is refreshed quarterly with the tier map.

Business driver An unstated journey lets vendor promises, senior manager pet projects, and the loudest team’s asks compete for platform attention on equal footing. A stated journey — grounded in the matrix — turns platform prioritisation into an evidence conversation. It also becomes the internal answer to the CFO’s "where is the ROI on all this" question, in terms (cells advanced, coverage-share delta, human-attention-per-outcome delta) that a CFO can audit.

How we measure this * Cells advanced per quarter, and the ratio of advancements to regressions. * Time from capability first-shipped to full auto-approval for each row-1 subclass (the archetypal one-shot). * Auto-approval rate at row 1, and the auto-approval blast radius (average number of files, services, and downstream callers touched by an auto-merged change).

Five tiers of repository readiness. Each tier unlocks the next class of automation. You cannot skip tiers — a repository at Tier 0 cannot receive agent-executed complex features because the prerequisites for verification and safe rollback are absent. Investing in tier lift is often the highest-leverage platform work available.

Viewpoint

The maturity matrix is a claim about the platform. The readiness ladder is a claim about each individual repository. Both must advance for the coloured region of the matrix to grow, because even a fully mature platform cannot safely run agent work against a repository that lacks the prerequisites — deterministic tests, runnable sandboxes, dependency manifests, safe rollback, and (critically at the higher tiers) MCP surfaces that expose the repository’s capabilities to agents.

The five tiers:

Concrete proposal Score every repository against the ladder. Publish the score. Fund the lift from Tier 1 to Tier 2 as the highest-return platform investment for organisations that have not yet done so — this is the tier boundary at which agent verification becomes trustworthy and the middle of the matrix opens up. Fund Tier 3 investment selectively, in repositories that anchor sweeps or coordinate across services. Tier 4 is a strategic bet, not a universal target — only the repositories that anchor cross-service and cross-repo change need it.

A single mandate — a CVE patch, a tracing SDK rollout, an auth wrapper migration — fans out across every affected repository. Each repository gets an ephemeral agent workspace running the same change with the same evidence contract. The platform batches PRs into waves and produces one aggregated evidence pack for a human sign-off at the sweep level. The human decides once for hundreds of repositories, not once per PR.

Viewpoint

Cross-repository sweeps are the broad-simple corner of the matrix: row 6 (many repos), left-half columns (mechanical implementation and verification per repo). They deserve their own treatment because the coordination cost — not the per-repo change cost — dominates the human effort today. A CVE that requires touching one hundred and thirty repositories currently consumes the same hundred and thirty human-hours of coordination attention regardless of how trivial each change is. The platform’s opportunity is to collapse the coordination attention into a single human decision at the sweep level, backed by an aggregated evidence pack.

The mechanism:

Concrete proposal Adopt sweeps as a first-class capability of the workspace broker (Appendix J) and the decision-packet system (the orchestrator chapter). Sweeps have their own autonomy tier — starting at sweep-T1 (agent-executed per repo, human sign-off per repo) for early adoption and progressing to sweep-T3 (agent-executed with a single sweep-level sign-off) as evidence accumulates.

Business driver Sweeps are the most under-served corner of the matrix in the industry pitch. Most agent-development tools address the narrow-complex corner (a smart pair-programmer for one file at a time). The economics of the broad-simple corner are unusually attractive because the human coordination cost is the dominant cost. Halving the coordination overhead for CVE waves alone can free a meaningful fraction of the security-response workforce for work that is not toil.

Risks and safeguards The primary risk is sweep-level errors that propagate through the fanout — a bad change applied to one hundred and thirty repositories at once. Safeguards:

How we measure this * Sweep throughput — sweeps executed per quarter, by class. * Coordination-hour reduction — human hours consumed per sweep, compared to the pre-platform baseline for the same class of change. * Sweep failure and rollback rate — sweeps that hit the failure budget and paused, sweeps that required rollback, and the root-cause distribution.

The matrix invites a reading it does not intend: that the job is to shade cells, and any cell will do. Read that way an organisation lights up plan across every complexity band, declares progress, and has automated nothing anyone can ship.

The sequencing that works is the opposite shape. Take one narrow class of change — the lowest row, the one with the most instances and the clearest evidence — and prove it through the entire loop before widening anything. Trigger to plan to implementation to test to review to deploy to production validation, with the evidence chain intact at every hop. One row, all columns.

That first slice is worth more than its own volume, because it is the only way to find out which part of the platform is missing. A gap in the trigger substrate, a repository that cannot be verified, a review policy nobody wrote down, an evidence store with no schema — these are invisible while the work stops at the fourth column and unmissable the first time something has to reach production without a person carrying it. Every slice proves the whole loop, or exposes where the loop is not yet a loop.

The order to widen in is then a question about evidence rather than ambition: dependency and CVE work first, because the volume is high and the correct answer is checkable; then simple corrective changes; then bounded features; then the broader workflows. Each step inherits a loop that already closes, so the new work is the new work rather than the new work plus the plumbing.

The cost of the other approach is not just slower progress. An organisation that widens before it deepens ends up with many half-automated stages, each needing a human to carry work across the gap to the next — which is more attention spent, not less, and the platform’s own meter says so.

The claims in this Part are only useful if the organisation reads them as directional. The platform will not be at the target state in twelve months. It will not be at the target state in twenty-four months. What it will be, if the matrix, the journey plan, the readiness ladder, and the sweep capability are all funded as concurrent investments, is meaningfully further along the journey than the alternative — which is a series of disconnected demos and vendor evaluations with no shared vocabulary and no measurement of progress.

The next Part turns to what has to be built to make any of this possible: the MCP-mediated foundations, the skills registry, the gateway, and the A2A coordination — the plumbing without which the matrix has no cells to shade.

A product manager facing a renewal problem does roughly this. Pull the last six months of tickets for the accounts at risk and read a couple of hundred of them. Listen back to three or four sales calls. Talk to five customers, two of whom say something that contradicts the theory. Notice that the same workflow shows up in eleven tickets under four different descriptions. Write that up, size it, argue for it against six other things, and turn the survivor into acceptance criteria.

The artifacts this produces are familiar to engineering — opportunity briefs, PRDs, journey maps, user stories, acceptance criteria, prototypes. The reading, the calls, and the argument are not, and they are where the judgment lives.

Three practitioners define the modern version of this work. Marty Cagan frames it as answering four risks before spending engineering capacity: value, usability, feasibility, and business viability (R371). Teresa Torres makes it continuous rather than a phase, with weekly customer contact and a tree that keeps proposed solutions attached to the problems they claim to solve (R372). Jeff Patton supplies the line this chapter turns on: shared documents are not shared understanding, and the written artifact is a record of a conversation rather than a replacement for having had one (R375).

Patton’s distinction survives contact with agents badly. When the record takes thirty seconds to produce, the conversation it was supposed to record becomes optional, and nothing in the finished document says which happened.

Microsoft’s experimentation platform reports that roughly a third of tested ideas improve the metric they were designed to improve. A third do nothing and a third make things worse (R373). Pendo’s feature-adoption work puts around 80% of features in cloud products at rarely or never used (R374). Older feature-utilisation studies point the same way on weaker methodology, and the direction is not seriously disputed by anyone who has looked.

Hold those next to a platform that triples delivery throughput. The hit rate does not move; the number of bets placed at that hit rate does. Each miss then carries maintenance, a share of reviewer attention, and a claim on the roadmap for as long as it stays in the product.

The upside here is real, and it is not "choose better." Cheap delivery makes being wrong cheap, which is the only route to a better hit rate anyone has ever demonstrated: smaller bets, faster invalidation, more of them. The cheap-experiments discipline in the orchestrator chapter is the delivery-side half of that. This chapter is the input side.

Take the case above and run it through the platform, because the mechanisms only make sense against a specific piece of work.

Monday. Three enterprise accounts have flagged renewal risk. A retrieval agent pulls every ticket, call transcript, and session recording associated with those accounts for the last two quarters, plus the same material from the twenty accounts most similar to them by size and usage pattern. It returns clusters with counts, each one linked to the tickets underneath it. Nine hundred tickets become fourteen candidate themes in about an hour. Nobody has been convinced of anything yet.

Tuesday. The product manager reads the underlying tickets for the four largest clusters, discards two of them as artifacts of how the support team files rather than what customers experience, and finds the eleven-tickets-four-descriptions problem in cluster three. An agent drafts the brief, with every claim carrying the ticket IDs behind it and a count of how many distinct accounts appear — six, out of twenty-three. That number is the interesting part of the draft, and no agent decided it mattered.

Wednesday and Thursday. The product manager calls five of the six accounts. Three describe the problem the cluster found. Two describe something adjacent that the cluster had split across two other themes, because the words they used share no vocabulary with the ticket text. The brief gets rewritten by hand.

Friday. The opportunity is recorded as evidenced rather than validated — the signal is real and the fix is a guess — and the specification that follows says so. It goes to delivery with the ticket IDs, the call notes, the sample size, and the product manager’s name attached.

Ten weeks later. Usage of the changed workflow is measured against the accounts the signal came from. If it moved, the opportunity closes as validated. If it did not, the invalidation is recorded against the same object, and the next person who proposes it finds out what happened last time before they spend a quarter rediscovering it.

One renewal problem, five days. Blue is agent work — retrieval, clustering, drafting against citations. Green is the work that stays human: reading the source material, the calls, the choice, and the name on the outcome. The reading collapsed from weeks to an hour; the calls did not move.

The agent did the reading. The human did the choosing, made the calls, and owns the outcome. That division is the whole design, and it is the same division the rest of the platform applies to code.

The material in that walkthrough already exists in every enterprise I have worked in, and mostly nobody reads it. Support tickets and resolution notes. Win/loss records and sales calls. Churn and renewal conversations. Session replays. Survey verbatims, community threads, feature requests, postmortems with customer impact, funnel telemetry. A quarter of it is more text than a product team can read in a year, and today the sampling is done by whoever is loudest in the Monday meeting.

High volume, unstructured, cheap to summarise and expensive to judge — the same shape as the work the platform already handles elsewhere. The adjacent pattern is in the ambient catalog as support triage (R.23), and the vendor space is mature enough that this is a build-or-buy decision rather than a research project (Enterpret R312, Kraftful R313, Unwrap R314, PostHog session-replay analysis R315, Productboard R104).

What the platform adds is the part vendors leave out: this material gets an owner, a schema, a freshness contract, and a retrieval path with the same permission model as everything else. A product manager asking why enterprise customers are churning should not get back verbatim text from tenants their role has no business reading, and the filter belongs at retrieval rather than on the way out.

Research transcripts and call recordings are the most sensitive raw customer data most companies hold, and they sit with the teams least likely to have a threat model. Source code belongs to the company. An interview recording belongs to a person who agreed to something specific.

What they agreed to was a researcher listening and taking notes. Processing by a third-party model was not on the table, and the processing being useful does not widen the grant after the fact. So what the customer consented to travels with the recording from the moment it is captured, and it constrains retrieval and outbound calls the same way a data classification does.

Deletion is where this gets hard, and discovery is the worst case in the platform because synthesis is the entire point of the material.

Five derivatives from one recording, each one further from the source and closer to a person who will read it. All five inherit the deletion, which is why a discovery pipeline that cannot say where a quote came from cannot honour the request. A customer asks for their interview to be deleted. The recording goes. Left behind: its transcript, its embedding, the theme it was clustered into, the quote pulled into a brief, and the slide that quote reached. All five inherit the deletion, and a pipeline that cannot say where a given quote came from cannot honour the request.

Discovery agents earn authority the same way every other agent in this document does: per task class, on measured evidence.

T4 is closed here, and the reason is about evidence rather than nerve. A code change can be checked before it ships — tests, policy, a canary. A problem choice cannot: the thing that tells you whether it was right is the market, and it answers months later. Where nothing can close the loop before the act, a person signs.

One exception holds. An organisation running live experiments with metric guardrails and automatic rollback has built something that does check a choice before it commits, for a narrow class of change — copy, layout, thresholds, ordering. Those can run at T3 under the experiment’s own kill switch, and the Autonomy Council names which classes qualify. That set is smaller than the enthusiasm for it suggests; a guardrail on click-through does not catch a change that quietly trains customers out of a workflow.

Comprehension debt is a reviewer who cannot explain the change. Cognitive debt is a team with no shared theory of the system. Intent debt is the third in the family: work in flight that nobody can explain the reason for, because the reason was never held by a person — only written down.

Naur’s argument that a program is a theory in the developers' heads rather than a text file (R352) holds for the product too. A specification is a theory about a customer, held by the team that built it. When the theory was never built, only rendered, the team keeps shipping plausible things and loses the ability to say which ones matter.

The mechanism is new even if the failure is not. A brief drawn from three tickets reads exactly like one drawn from forty interviews, because the writing is no longer produced by the person who did or did not do the work. Reviewers used to catch thin thinking by its prose. That signal is gone, and the only one left is where the evidence came from — which means it has to be attached to the document rather than remembered by its author.

So the record carries the ticket IDs, the sample size, the segments represented, and the person who will defend it. And it carries one of four states: hypothesis, evidenced, validated, invalidated. Committing to a hypothesis is a normal thing to do; committing to one while believing it is validated is how a quarter disappears.

Synthetic participants deserve naming before someone buys one. Simulating customer interviews with generated personas is appealing to a team under discovery pressure, and the research does not support it: models match some aggregate human judgments and diverge on others, with no reliable way to know in advance which kind of question yours is (R376). It reproduces the result from METR, the Model Evaluation and Threat Research group (R354), one stage upstream — faster work, weaker contact with reality, and a bill that arrives when the launch lands flat. Rehearsing an interview guide against a simulated participant is fine. Recording one as evidence is not.

The organizational chapter notes that a product manager can now build a working prototype. Make that a supported path rather than a curiosity: the same ephemeral workspace engineering uses, at T0, with the auth wrappers and tenant scoping already wired, torn down on the same schedule.

A prototype answers usability and value questions a document can only assert, and its acceptance criteria feed the test generation described in the orchestrator chapter. Three things keep it from becoming a debt source:

Appendix K gains two objects in front of the outcome, with their fields listed there. A signal is one piece of customer or operational evidence with its source, date, tenant, segment, consent, and retention. An opportunity is a clustered problem statement with the signals underneath it, a sample size, an owner, and a validation state.

The lineage then runs end to end — signal, opportunity, specification, work item, execution task, change set, decision packet, release, operational event, learning — and the learning step writes back to the opportunity instead of stopping at the platform.

The evidence chain with its upstream half attached. The two blue objects are new; everything from the specification rightward already existed. The dashed return is the part that was missing — what production learned lands against the opportunity that proposed it, so the next person to raise the same idea finds the answer. Two rules come with it: nothing enters delivery without a named owner and a validation state, and an invalidated opportunity keeps its evidence.

Three questions become a query rather than an excavation. Which customer signal motivated the change behind this incident. What shipped for the accounts that churned, versus what they asked for. Which specifications entered delivery with nothing linked at all — the one that can be enforced at the gate.

Five pieces, in the order they pay back:

Platform Engineering builds the repository, the gateway integrations, and the workspace profile. Product Operations owns the schema and the consent classification. The Autonomy Council authorises the tier map. The cost is modest against the rest of the programme: the material is text, the agents are continuous low-burn, and the expensive part is the retrieval and consent plumbing rather than the inference.

Three failure modes are worth watching from the first sprint. A system that clusters customer conversations at volume is one permission change away from profiling individuals, and the distance is a policy rather than a rewrite. Clustering also amplifies whatever bias the material already has — customers who file tickets are systematically not the customers quietly leaving, and a synthesis engine states the resulting picture with more confidence than a human reader would. And if agents absorb the reading while customer-contact hours stay flat, the organisation has automated the activity that produces senior product judgment, which is the learning-pathway collapse the organizational chapter identifies for junior engineers, arriving in a different function.

Metrics tied to this chapter (definitions consolidated in Appendix T):

Nine metrics, and the first one carries most of the weight. It costs a field on an existing object, it is hard to argue with, and it turns the claim this chapter makes into something the platform can enforce rather than recommend.

Viewpoint

Mature engineering organizations already have internal developer portals and paved roads. A human can enter a few details and create a repository, scaffold a service, connect CI/CD, register ownership, and provision standard infrastructure. These systems are not necessarily AI, but they embody years of operational and security learning.

The paved path is the internal developer portal, carrying years of security and operational learning. The worn track is what happens when the prompt can reach the building and the paved road cannot.

The next step is to make those capabilities accessible from the developer’s prompt. An agent should be able to retrieve internal documentation, discover the approved SDK, ask the service catalog who owns a dependency, or invoke the same service-creation path used by the portal. Otherwise the prompt becomes a new front door that bypasses the organization’s best investments.

This does not mean wrapping every web page in a chatbot. It means exposing stable, well-described capabilities. The point-and-click portal can remain a valuable human surface over the same underlying contracts.

A peer example. Spotify’s Backstage is the canonical implementation: their Golden Paths encode approved templates, ownership, and lifecycle inside a service catalog beneath the human portal. An AI-native platform should expose the same catalog and template APIs as MCP tools so agents scaffold services through the paved road rather than re-inventing it in a prompt (R356).

Concrete proposal Expose high-value platform capabilities through stable, well-described MCP or REST interfaces and publish approved specialist agents through A2A where stateful delegation adds value. Place enterprise policy at the access boundary.

Business driver and expected gain If the prompt becomes a new front door but cannot reach approved platform capabilities, agents will bypass years of security and operational learning or send the developer back to manual work.

Organizational requirements Capability owners need publication standards, versioning, support obligations, permission models, evaluation, and deprecation processes. Security and platform teams must jointly operate catalogs and gateway policy.

Cost and investment Costs include interface hardening, MCP servers, A2A endpoints, gateway infrastructure, identity integration, observability, and lifecycle support. Reuse the contracts beneath existing portals to avoid parallel implementations.

Risks and safeguards Credential sprawl, brittle interfaces, tool poisoning, excessive permissions, recursive delegation, and incompatible versions can undermine the benefit. Prefer least privilege, short-lived credentials, signed provenance, loop limits, revocation, and documented REST fallback.

Relationship to the wider plan Agent-accessible paved roads join knowledge, tool interfaces, orchestration, and governance. MCP and documented REST expose capabilities; A2A supports collaboration with independently operated specialist agents; gateways apply cross-cutting controls.

Supporting material The MCP and A2A specifications support complementary agent-to-tool and agent-to-agent interaction models. A2A reported broad ecosystem support in 2026, though adoption should still be evaluated workflow by workflow. See [R9, R10, R29–R32].

Viewpoint

A sufficiently large organization has its own ways of building software. A team may require an approved Spring security component around REST controllers, an internal Kafka wrapper rather than direct Kafka usage, or an OpenAPI-first approach that generates controllers. There are SDKs, code styles, architecture decisions, service ownership records, runbooks, approved examples, and security practices that a general model cannot infer reliably.

This material has traditionally lived in wikis, developer documentation, tribal knowledge, examples, and point-and-click portals. In an AI-native lifecycle, it must reach the agent inside the task. A defect-fixing agent running in an agent workspace should not make “industry average” choices when the organization already has a supported paved road.

The same knowledge should participate in generation, review, testing, migration, support, and operations. If a security standard changes, the organization should not separately update a wiki, onboarding deck, reviewer checklist, prompt snippet, and runbook with no assurance that they agree.

Implications

The phrase “organizational knowledge as a runtime dependency” captures the idea. Skills can be thought of as compiled organizational knowledge: policy, conventions, examples, and procedures transformed into something agents can apply. The metaphor is useful, but it implies lifecycle responsibilities—ownership, provenance, freshness, permissions, tests, and retirement.

Organizational knowledge as runtime context. Governed sources are curated, evaluated, permission-filtered, and improved through verified outcomes.

Organizational knowledge as a runtime dependency

Context flow. The model is not the organization’s intelligence; governed internal knowledge is supplied at the point of work.

Concrete proposal Treat engineering knowledge as a governed runtime supply: identify authoritative sources, assign owners, version important guidance, retrieve only task-relevant material, and record which context influenced each outcome.

Business driver and expected gain Generic models do not know an enterprise’s approved libraries, architectural decisions, ownership, or operational history. Missing this context creates rework, policy violations, and plausible solutions that do not fit the organization.

Organizational requirements Architecture, security, platform, service teams, and documentation owners must curate canonical guidance and resolve conflicts. A knowledge product owner should govern freshness, access, feedback, and retirement.

Cost and investment Investment covers content cleanup, metadata, indexing, retrieval, permissions, provenance, evaluation, and ownership. Ongoing maintenance can exceed initial technology cost if source quality is poor.

Risks and safeguards Stale, contradictory, overshared, or poisoned context can scale mistakes across the fleet. Enforce source authority and permissions, expose citations, evaluate retrieval, and provide a route to correct the underlying source.

Relationship to the wider plan The knowledge supply serves generation, review, testing, support, security, and operations. MCP, REST, retrieval, skills, and portals are delivery mechanisms; ownership, freshness, provenance, and evaluation make the knowledge dependable.

Supporting material MCP formalizes resources, prompts, and tools, while current context-engineering practice emphasizes careful context selection and tool design. The supply-chain framing remains this document’s synthesis. See [R9–R11].

Viewpoint

Documentation is only one part of how knowledge reaches an engineer. In a large organization, developers often need to discover the right Slack channel, wait across time zones, find the current owner, and reconstruct a problem for a scarce expert. The cost is not just support effort. The entire delivery flow pauses while the right knowledge is located.

An AI-native platform can attempt self-service first: retrieve the relevant knowledge, inspect the actual failure, run safe diagnostics, and propose a known remediation. When that is insufficient, it should route the issue to the correct person with the task context already assembled. Once resolved, the answer should improve documentation, routing, skills, or diagnostics so the organization does not pay the same latency repeatedly.

Implications

“Organizational latency” is the elapsed time required for the right knowledge—documented, encoded in tools, or embodied in people—to reach the work. This is broader than developer support ticket time. It connects the attention thesis, ownership, internal platforms, and organizational learning.

Developer support and organizational latency

Developer support loop. Self-service and AI assistance precede a context-rich escalation; the resolution improves the system.

Concrete proposal Create a support agent that starts with permission-aware retrieval and safe diagnostics, routes unresolved issues to the correct owner with context assembled, and converts each resolution into improved knowledge or automation.

Business driver and expected gain Delivery pauses while engineers locate the right owner, wait across time zones, or reconstruct a problem for a scarce expert. Repeated support questions also consume expert capacity that could improve the platform itself.

Organizational requirements Support channels need explicit ownership, escalation agreements, feedback loops, and incentives for experts to improve reusable guidance. Platform teams should own recurrence reduction, not only ticket closure.

Cost and investment Investment centers on integrations with support channels, ownership data, diagnostics, retrieval, and capture workflows. Value comes from shorter waits, fewer repeated questions, and more expert time returned to platform improvement.

Risks and safeguards A confident but wrong answer can delay recovery, sensitive context can leak, and automation can hide ownership gaps. Preserve provenance, start with read-only diagnostics, make escalation easy, and measure recurrence and correct-owner routing.

Relationship to the wider plan The support loop uses the same context supply, ownership graph, diagnostics, decision packets, and learning system as the SDLC. A resolved escalation should improve documentation, routing, tools, or automated remediation.

Supporting material The organizational-latency term is a synthesis in this document. DORA’s system-level findings support measuring the surrounding delays and constraints rather than treating local coding speed as the outcome. See [R1–R3].

Viewpoint

Every previous section in this chapter has treated the what of agent access — MCP, skills, paved roads, developer support. This section names the when and the with-what: the infrastructure that decides when an agent runs, and the infrastructure that assembles the right context around that agent at runtime. Both are platform capabilities that the industry pitch tends to leave implicit inside "the agent does its work." At enterprise scale they are the difference between an agent that behaves as a governed platform citizen and one that behaves as a security incident waiting to happen.

An agent invocation is not a function call. It is the composition of four decisions the platform must make explicitly:

The MCP gateway and the workspace broker (the operating-models chapter) answer the second and fourth. This section answers the first and third.

"Agent" names a category, not a construction. Inside it sit a handful of recurring shapes, and the choice between them is not a matter of sophistication — it decides what evidence the thing can produce, and therefore how much authority it can ever earn.

That is the connection this document cares about. The patterns below are well described elsewhere as engineering choices; here they are read against the autonomy ladder, because a capability’s tier ceiling is set by the strength of the evidence its shape can generate, not by how capable the underlying model is.

The grouping and its sequence are taken from a practitioner infographic that circulates widely under the title AI Agent Design Patterns (R405); the individual shapes are older than it and are sourced to their own papers below. The descriptions, the evidence table, the tier ceilings and the composition figure are this document’s.

An engineer evaluating a coding agent, an ambient monitor, or a customer-built agent needs a checklist. Ten properties tell you whether an agent is safe to point at production or customer data.

An agent that fails any of these is held at a lower autonomy tier until the property lands. That is the platform’s answer to "is this agent safe to deploy."

MCP servers come in two shapes and the platform treats them differently.

Local MCPs run on the engineer’s laptop or inside the agent’s workspace, over stdio transport. They give the agent access to things at the same trust boundary as the agent itself: the local filesystem, a specific git repo, a sqlite database, puppeteer for browser automation, a bespoke CLI tool. The official reference servers — everything, filesystem, git, sqlite, puppeteer — are the canonical shapes.

Local MCPs are governed by the workspace broker’s placement: what compute the workspace runs on, what filesystem it can see, what network it can reach. There is no over-the-wire auth because there is no wire — the MCP is a subprocess of the agent’s runtime, dying with the workspace.

Cloud MCPs run remotely and expose enterprise systems over HTTP with server-sent events. Public examples: the GitHub MCP server, Linear’s MCP, Notion’s MCP, PagerDuty’s MCP, Slack’s MCP, Google Drive’s MCP, and the hosted MCP servers shipped by the major content platforms. Enterprise-hosted equivalents cover Jira, ServiceNow, Salesforce, internal service catalogues, feature-flag systems, and cost telemetry.

Cloud MCPs are the case OAuth 2.1 with resource indicators, PKCE, audience-bound tokens, and no token passthrough was designed for. Every cloud MCP call flows through the platform’s MCP gateway; the gateway holds delegated authority on the agent’s behalf and mediates identity, scope, quota, and audit. When a local MCP reaches out to a cloud MCP, the local server routes through the gateway too — the workspace placement policy makes that enforceable.

The failure mode when the distinction is not enforced: an agent running a "local" MCP that quietly proxies to a public API, bypassing the gateway’s audit and DLP. The workspace broker’s egress control catches this; placement plus egress proxy together are the enforcement.

The tools an engineer builds for one-off work — a script that queries an internal API, a wrapper around a stubborn CLI, a throwaway scraper — get MCP-enabled by default. Ten-line stdio server, one manifest, one paragraph of documentation. That gets the tool identity, scope, audit, rate limiting, and composability into agent workflows for free.

The alternative — engineers pipe raw API keys into agent prompts, or paste the tool’s source into a chat window and hope the model figures it out. Both leak credentials, defeat audit, and make the tool uncomposable with any other agent workflow.

Retirement matters as much as authoring. Ad-hoc MCPs go into the skills registry with a provisional flag and a 90-day sunset. Renewal requires a maintainer, a test, and a use case. Ad-hoc MCPs that survive 90 days become skills; the rest disappear.

At any given month in a mid-sized enterprise the number of throwaway tools engineers write is measured in hundreds. MCP-enabling them by default turns that tail into a governable surface instead of a proliferation of loose scripts each with its own credential.

Viewpoint

Every proposal in this document funnels through platform primitives — the workspace broker, the MCP gateway, the decision packet, the Autonomy Council, the ambient-portfolio scan, the constitution review. That funneling is the point: it is what makes the system governable at all. It is also, if left unmanaged, how the platform becomes the new bottleneck it was meant to remove. If the platform team is 12 people and 40 product teams are waiting on constitution reviews and capability approvals, "organizational latency" has merely shifted address: the wait now lives in the platform queue rather than in the wiki, and the developer experiences it as the same delay under a different name.

Implication and counter-measures

The failure mode is real but not automatic. The platform must be designed to escape it, not merely to hope it does not happen. Four counter-measures belong on the platform roadmap from day one:

Metrics tied to this chapter (definitions consolidated in Appendix T):

Eleven metrics; each pairs with a mechanism from this chapter.

A soft rail encodes a decision the organisation has already made, in a form an agent loads at the point of work, so that nobody re-litigates it in a prompt.

That is the whole definition, and the forms it takes are varied: a skill packaging an internal SDK with its conventions and tests; a review command that runs the security checklist a staff engineer would apply; a hook that fires on every commit; a subagent definition with its own narrow prompt and tool set; an MCP server that exposes the deployment path; a scaffold; a prompt fragment that states how this organisation writes commit messages.

The distinction from documentation is the one that matters. A wiki page describing the auth wrapper is read when someone already knows to look for it. A skill that supplies the auth wrapper is loaded at the point of work, and it fails loudly when it is wrong.

The gap between a convention an agent can load and one it cannot is close to total. In an evaluation of repository context files across three coding-agent harnesses, a build tool named in the context file was invoked 1.6 times per task on average, and under 0.01 times per task when the file did not name it (R387). Documentation describes; soft rails execute. Organisations with excellent documentation and no soft rails are the common case, and their agents behave as though the documentation does not exist — because, from the agent’s position at the moment of work, it does not.

Adherence is not the same as benefit, and the distance between them is the argument for a review bar. On a benchmark where agents had to find the relevant skill themselves, curated skills lifted the average pass rate from 33.9% to 50.5%, while skills the agents wrote for themselves moved it slightly negative and the gain ranged from +4.1 to +25.7 points depending on the model and harness (R386). Publishing a capability an agent will load is easy. Publishing one worth loading is the harder half, and the reason the publication tiers below carry a rising review bar.

The relationship to the agent constitution is worth stating precisely, because the two are easy to conflate. A constitution says what an agent may not do and what it escalates; it is enforced by the runtime and an agent cannot opt out. A skill says how this organisation does a thing; it is adopted because it is available and good, and an agent can ignore it. When they disagree the constitution wins, and the constitution is where that ordering belongs — otherwise a well-meaning skill that says "always deploy after tests pass" quietly grants an authority the tier map withheld.

The hard rails pass both changes, because neither violates anything. Hard rails bound the space of permitted actions; soft rails decide which path through that space an agent takes by default. This is why an organisation that invests only in enforcement gets agents that stay inside the fence and reinvent everything differently.

"Plugin" has become a broad word. In practice an organisation ends up with soft rails on many more surfaces than the word suggests, and the temptation is to govern them as one category because they arrive through similar registries. That under-protects one end and over-governs the other.

Two properties classify them. Who invokes it — a person, or an event. Whose credentials it runs with — the user’s, an ephemeral workspace’s, a pipeline’s, or a standing service identity — which also settles what it can reach. The failure that matters in each row below follows from those two: a review command a developer types is a different risk object from a hook that fires on every push with pipeline credentials, even when both ship in the same bundle.

The classifying facts are invocation and authority; file format is a packaging detail. Set the review bar per class. A skill that only supplies text into a context window and a hook that executes with pipeline credentials do not deserve the same approval path, and a registry that cannot tell them apart will either wave the second one through or bury the first in process.

Two of these surfaces deserve an explicit position because they sit outside the platform’s control plane. IDE extensions run on the developer’s machine with the developer’s credentials — the workspace broker never sees them, the egress proxy never sees them, and the audit trail does not include them. Treat them as personal tooling with a published allowlist, and keep anything that touches customer data out of them. The platform cannot govern what it never observes.

Pipeline steps have the opposite problem: they are fully governed and routinely over-credentialed. OWASP ranks insufficient pipeline-based access controls fifth in its CI/CD top ten, and names the mechanism — credentials shared across contexts and never rotated, so the population of things holding valid credentials only grows (R390, R391). Most estates have not reached short-lived credentials at all: 58% of organisations running AWS with GitHub Actions still authenticate their pipelines with long-lived IAM-user keys (R392). A soft rail that runs in CI inherits whatever those keys can do.

A skill that lives in one engineer’s home directory is a personal tool, which is a fine thing to be. The organisational value appears only when it is discoverable by someone who did not write it, and that requires a registry with the same contract the platform applies to managed context repositories: a named owner, a schema, a freshness contract, a retrieval interface, provenance, and a retirement path.

Four mechanics carry most of the weight.

Tiered publication. Personal, team, and organisation-wide, with the review bar rising at each step and the blast radius rising with it. Most soft rails should never leave the team tier, and a registry that pushes everything to org-wide produces a catalogue nobody trusts. The provisional flag already described for MCP entries applies here too: publish provisionally with an expiry, and require evidence of use before graduation.

Versioning and pinning. An agent that silently picks up v2 of a review skill mid-sprint produces different output than it did yesterday, and the engineer has no way to know why. Pin versions in the workspace definition, make upgrades a visible change, and keep the previous version resolvable for as long as anything references it.

Discovery at the point of work. A registry nobody searches is a folder. The test is whether an agent finds the right skill without the engineer knowing it exists — which means the registry is indexed into the same retrieval path as everything else, and each entry carries a description written for that purpose.

Usage telemetry as the curation input. Which skills are loaded, by whom, how often, and whether the output was kept. Without it, curation is opinion, and the catalogue fills with well-intentioned entries that nobody has invoked since the quarter they were written.

The same soft rail should behave the same way on a developer’s laptop, inside an ephemeral agent workspace, in CI, and inside an ambient agent. It frequently does not, and the gap is where trust in the whole layer erodes.

The usual breakages are mundane. A skill that shells out to a tool present on every laptop and absent from the CI image. A local MCP server over stdio that has no cloud equivalent, so the workspace version silently does less (the foundations chapter). Credentials that resolve to a person locally and to a service account in the pipeline, with different reach. An interactive confirmation that prompts on a laptop and hangs forever in a non-interactive runner. Filesystem assumptions that hold in a checkout and fail in a sparse workspace.

Make parity a declared property rather than a hope. Each registry entry states which runtimes it is tested against, and the test suite runs in each of them. A skill that works only on a laptop is a personal tool — label it, do not promote it, and do not let a CI pipeline discover it the hard way.

The moment a skill is loaded by every agent in the organisation, it has the reach of a dependency and the review treatment of a wiki page. That asymmetry is the central risk of this layer, and it takes six forms.

The stale skill. It encodes last year’s pattern, and now every agent produces last year’s pattern, confidently, at volume. This is worse than having no skill, because the output looks house-conformant to a reviewer. A freshness contract with a named owner and a review date is the mechanism; usage telemetry tells you which stale entries actually matter.

The description as an injection surface. Skill and tool descriptions are read into a context window, and models act on them. A benchmark across 45 live MCP servers and 20 agents found instructions hidden in tool metadata succeeding as often as 72.8% of the time, with no evaluated agent refusing in more than 3% of cases (R393). A description that says "always run this before any other check" is an instruction someone shipped, whether or not they meant it as one — the published attacks are all adversarial, but instruction-following does not care about the author’s intent. The protocol itself tells clients to treat tool annotations from untrusted servers as untrusted (R394), a description deserves the same treatment, and both deserve review with the same seriousness as the code.

Third-party supply chain. An external plugin is a dependency that executes in your engineers' context. Pin versions, review the diff on upgrade, and never auto-update org-wide. The organisation that would not accept an unreviewed npm package should not accept an unreviewed capability package on the strength of it being useful.

Blast radius and the kill switch. Two questions worth being able to answer within the hour: who is currently using this skill, and can it be disabled everywhere without a deploy? Both require the registry to know its consumers, which only happens if it was built to record them.

The cost of the catalogue. Everything the organisation publishes competes for a finite context window, and a registry judged on reuse has every reason to grow. Selection degrades as it does: function-calling accuracy falls by between 7% and 85% as the number of available tools rises (R388), and on a large tool index, selection accuracy measured 13.62% when the whole index was presented at once against 43.13% once retrieval narrowed the candidates first (R389). Context that is loaded also has to be paid for — repository context files raise inference cost by over 20% on average with no matching gain in task success (R387). This is the measured case for keeping most soft rails at the team tier: an org-wide catalogue is not free to the agents that have to read past it.

Skills that disagree. The constitution beats a skill, but two skills have no such ordering, and tiered publication makes the collision routine — a team convention and an org-wide one both load, both claim the same ground, and the agent arbitrates. Put the precedence in the constitution next to the constitution-wins rule: the more specific tier wins, and an entry that knowingly departs from an org-wide capability says so in its description, so the agent is resolving a declared conflict and not an accidental one.

None of this argues for a heavy approval process. It argues for the review bar to match the class from the surface table, for provenance and version to travel with every entry, and for the organisation to know what would happen if one entry turned out to be wrong.

The chapter so far argues what a soft rail is and what it costs. This section is the survey: what the layer looks like in practice, now that the ecosystem is large enough to have a shape.

The public ecosystem is where capabilities come from. It is not where an organisation should let its agents shop. A marketplace measured in hundreds of thousands of entries is a supply, and what an engineer needs at the point of work is a short list that is already true for their project.

So the registry described earlier grows into something with a sharper job: an internal marketplace that curates from outside and inside, recommends against a context rather than a search box, and binds a chosen set to a project the way a dependency manifest binds libraries.

The themes, not the entries. An organisation will publish dozens of capabilities per phase and no two organisations will publish the same ones, but the shape of the coverage is stable — and the gaps are visible from the picture. The centre is what makes the ring a platform rather than a folder.

Nearly every valuable soft rail starts as somebody’s one-off. The graduation path matters more than the authoring guidance, because the failure is not that people write bad skills — it is that good ones never leave the directory they were written in.

The graduation path, with retirement as a first-class exit. The provisional tier is the important one: publishing with an expiry and requiring evidence of use before graduation is what keeps the catalogue trustworthy.

The same path applies to a one-off script becoming a registered MCP tool, which the foundations chapter describes from the tool-surface side. What makes a good entry is unglamorous: narrow enough to compose, tested against golden cases, explicit about its failure mode, and named for its function — rotate-tenant-keys, not platform-tools-v2. The anti-pattern is the mega-skill that encodes an entire workflow end to end — it cannot be recombined, it goes stale as a unit, and the first team whose process differs slightly forks it.

Soft rails belong across the whole lifecycle, not only in code generation, and the coverage gaps are usually obvious once someone looks:

Design systems are treated as a discipline apart, and for soft-rail purposes they are not. A design system holds exactly what the rest of this chapter describes: tokens, approved components, accessibility rules, interaction patterns, brand standards, layout conventions, reference implementations, and the dependencies the organisation accepts. That is organisational knowledge, and an agent needs it at the point of work for the same reason a backend agent needs the internal HTTP client.

An agent left to infer UI primitives will invent them, competently and inconsistently, in the same way it hand-rolls a retry loop when the auth wrapper is a wiki page. The failure looks different — a component that behaves almost like the real one, an accessible name that is nearly right — and it is harder to catch in review, because the result looks house-conformant to anyone who does not know the system well.

So the design system belongs in the registry on the same terms as everything else: an owner, a version an agent can pin, a freshness contract, and a retrieval path that reaches the agent rather than waiting to be browsed. Where it already exists as a component library, most of the work is publishing it as something loadable and keeping the guidance and the code from drifting apart.

Platform engineering builds the substrate — the registry, the parity test harness, the telemetry — and the handful of highest-leverage capabilities that everyone needs. Teams build their own, because the conventions worth encoding are mostly local. The registry is the shared surface between them, and the platform team’s real product is that surface rather than the catalogue.

The incentive problem is real and rarely named: nobody is promoted for writing a skill that saves other teams a week. Usage telemetry is the cheapest available fix, because it turns "I wrote a thing" into "four hundred agent sessions used this last month", which is evidence a promotion committee can read. The change-management chapter’s argument applies directly — this is platform adoption work, and it fails for the same reasons platform adoption usually fails.

One caution against over-centralising. A platform team that insists on authoring every org-wide capability becomes the bottleneck it was meant to remove, and teams route around it with private scripts that nobody can see. Own the review bar and the substrate; let the authorship be wherever the knowledge is.

Metrics tied to this chapter (definitions consolidated in Appendix T):

Of these, the first two are the ones to instrument first. Reuse rate says whether the layer exists in practice; lifecycle coverage says whether it exists everywhere the work does, which is usually where the surprise is.

Viewpoint

Security cannot remain a late meeting in which a security representative receives an incomplete architecture diagram and is asked for approval. AI-assisted development creates an opportunity for code and systems to be reviewed and re-reviewed continuously, using specialized analysis where useful, while security experts concentrate on novel threats and difficult judgment.

The urgency also rises because attackers can use AI to search for weaknesses. The organization needs AI for assurance as well as feature creation and defect fixing. This includes code review, dependency and configuration analysis, policy checks, architecture evidence, threat discovery, and support for remediation.

Supporting evidence and boundary

NIST’s AI risk guidance and secure-development profile support lifecycle risk management, while OWASP’s agentic guidance highlights tool misuse, identity and privilege abuse, behavior hijacking, and poisoned context. [R4–R6] These sources support continuous controls; they do not determine where human security expertise or approval belongs in a particular enterprise.

Concrete proposal Embed security agents and deterministic controls throughout design, coding, review, testing, deployment, and operations. Separate reasoning from enforcement and require progressive authority for any action that changes protected systems.

Business driver and expected gain Agent speed increases both the volume of change and the reachable attack surface. Periodic review based on stale diagrams cannot provide adequate assurance when code, tools, dependencies, and runtime conditions change continuously.

Organizational requirements Security engineering must co-own policies, threat models, evaluation data, exception handling, incident response, and gateway controls with the developer platform. Service owners remain accountable for accepted risk.

Cost and investment Investment includes security models and scanners, policy enforcement, sandboxing, identity, audit retention, red-team exercises, and specialist review. Earlier detection should reduce late remediation and incident cost.

Risks and safeguards Agents can misuse tools, inherit excessive privilege, follow injected instructions, expose data, or generate noisy findings. Use isolation, least privilege, trusted context, independent verification, approval gates, revocation, and emergency stop controls.

Relationship to the wider plan Security participates in the context supply, gateway, review, test, deployment, and operations loops. Identity, least privilege, isolation, provenance, approval, and rollback form a control plane across every lifecycle stage.

Supporting material NIST provides lifecycle risk and secure-development guidance; OWASP catalogs agentic threats; MCP specifies authorization mechanisms but does not replace an enterprise governance program. See [R4–R6, R9, R10, R13–R19].

Viewpoint

An agent that can act needs an explicit answer to three questions before it takes its first action: what may it do, what must it do, and what must it never do. Prompt engineering has been the informal answer since 2022, but a prompt buried in application code is not a policy artifact — it is not reviewable, not versionable, not auditable, and not enforceable independently of the runtime that executes it. The industry-emerging term for the reviewable, versionable, enforceable artifact is the agent constitution.

Distinguish this from Anthropic’s Constitutional AI (Bai et al., 2022, R284), which is a training methodology that shapes model behavior at pre-training time by giving the model a set of principles to critique its own responses against. The enterprise agent constitution is a runtime policy artifact — a document read by the platform, enforced by the gateway, tested by the evaluation harness, audited on every use, and versioned like code. Both matter; they operate at different layers.

Implication

The orchestration platform must treat an agent constitution as a first-class artifact with:

Constitutions compose in a hierarchy:

Constitution hierarchy. Enterprise principles bind all agents; team constitutions add domain-specific rules and may narrow but not widen the enterprise scope; capability constitutions specify per-capability behavior; agent-instance context is bound at task start. A rule denied at any higher level cannot be granted at a lower level.

Concrete proposal

Every agent capability in the registry references a constitution document (stored in version control, reviewed like code, signed before deployment). The gateway loads the composed constitution at task admission and enforces the machine-readable rules; the model receives the human-readable principles as part of its system prompt; the eval harness tests the agent against a scenario suite derived from the constitution before the capability is promoted to a higher autonomy tier. A capability that changes constitution version requires re-authorization by the Autonomy Council for T3+ tiers.

Two examples

Risks and safeguards

The failure mode is treating the constitution as marketing copy — a document that sounds good in a review meeting but the runtime does not actually check. Safeguards: every machine-readable rule has a test in the eval harness; every human-readable principle is quoted in the runtime system prompt (not paraphrased); the gateway logs every rule evaluation and its outcome; the constitution version and its evaluation status are fields in every decision packet.

Relationship to the wider plan

The constitution is the class-definition mechanism the Autonomy Council uses to authorize T3 and T4 capabilities. The autonomy ladder in the glossary refers to "class definitions" as what the Council owns; the constitution is the class definition. Constitutions also underpin the ambient-agent governance model in the ambient-agents chapter: an ambient agent with no per-task human sponsor is only trustworthy because its constitution is trustworthy.

A peer precedent. The Autonomy Council mechanism has direct precedent in Amazon’s Bar Raiser — an independent, trained authority attached to a consequential decision (hiring) that a local team otherwise owns (R358). Amazon’s Correction of Errors document is a similar shape for post-incident learning: a structured artifact written for organizational memory rather than blame, with mandatory actions. Both patterns show that a standing cross-team review body can scale without becoming a queue if its scope is bounded and its decisions carry weight.

Open questions

Viewpoint

An agent that reads a repository, browses a wiki, calls an internal tool, or executes a task is processing regulated data the same way a production service does. The residency, retention, and cross-border posture of the customer’s data must be respected by the workspace the agent runs in, the model the agent calls, the evidence store the platform writes to, and the audit surface the compliance team reads. Silence on residency turns the orchestration platform into a compliance regression.

Implication

The orchestration platform must expose residency as a first-class attribute of every workspace class, model route, and evidence store. Model routing (see the cost and routing section later in this chapter) must be residency-aware: a request that carries EU-tenant data cannot be answered by a US-only model endpoint even when that endpoint is cheaper or faster. The workspace broker (see the operating-models chapter) must refuse to place a task whose inputs cross a boundary the tenant has not authorized. Evidence packets must record which region processed which input, so that a subject-access or deletion request can be honored across the whole chain, not only at the point of ingestion.

Concrete proposal

Every workspace class, every model route, and every MCP tool registration carries a residency attribute drawn from a small enumerated set (US, EU, UK, JP, IN, sovereign-cloud, and customer-attested). The workspace broker enforces the residency policy before task placement; the model router enforces it before model selection; the evidence store partitions writes by residency. FedRAMP, SOC 2, and ISO 27001 posture become build-time attributes of the workspace class rather than manual reviews at deployment time.

A peer example. Databricks' Mosaic AI Gateway combined with Unity Catalog is a working implementation of residency-aware model routing (R362): model endpoints carry region attributes, requests are matched to endpoints by data-classification tag, and prompt/response is logged into a governed store. The IP-posture record proposed here is one metadata field away — the routing and gating primitives already exist and are documented.

Open questions

Viewpoint

Enterprise customers do not adopt an AI-native platform on capability alone. They adopt it once they can answer three questions from legal review: who owns the output, who indemnifies the enterprise if the output infringes, and what training data the model was built on. A strategy document that treats these as procurement details rather than architectural inputs will not survive first contact with an enterprise legal team.

Implication

Model choice and vendor selection are not only cost/quality decisions; they are IP-posture decisions. The platform must record, per model route, the vendor’s position on output ownership, indemnification (with any caps and carve-outs), training-data opt-out for customer inputs, and audit rights over training-data provenance. That posture becomes a routing input alongside quality, latency, and cost — a low-cost model with weak indemnification is not interchangeable with a higher-cost model that carries full IP protection for the same task class.

Concrete proposal

The model registry carries an IP posture record per route: output ownership statement (customer owns / vendor owns / mixed), the indemnification tier the vendor offers (none / capped / full), the training-data opt-out status for customer prompts and outputs, and the vendor’s own commitments about training on customer data. Sensitive change classes (production code, security-relevant patches, customer-content transforms) route only to models with full indemnification and confirmed training-data opt-out. The platform publishes an IP-posture report per pull request as part of the decision packet, so the merge decision includes IP posture, not only technical correctness.

Open questions

The IP posture above governs who is liable for the output. The operational counterpart — who saw the input, where it went, and how the customer sees and constrains that flow — is a separate discipline covered in the next section.

Viewpoint

Every prompt sent to an external model is an outbound data flow to a third party. The moment an agent reads customer content, generates a prompt from it, and calls an external LLM API, that content — or some derivative of it — has crossed the enterprise trust boundary. If the enterprise has customer contracts stipulating how customer data is handled, those contracts now bind the model vendor whether the customer knows it or not.

This is separate from the IP question addressed above. IP asks who owns the output and who indemnifies the enterprise if the output infringes. Customer-data controls ask who saw the input, where did it go, how long is it kept, and can the customer see and constrain that flow. Enterprise legal teams treat the two as independent gates — a strong IP posture with weak input controls still fails their review.

Implication

The orchestration platform must treat every outbound call to an external model as a governed data-egress event, with the same seriousness as an outbound API call carrying customer data to any other third party. That means data minimization on the way out, contractual constraints on the receiving vendor, auditability, and customer transparency.

Concrete proposal — six controls

Business driver and expected gain

Enterprise sales cycles increasingly require explicit answers to "where does our data go when your platform uses AI?" before a deal closes. A platform that cannot answer this precisely — with the sub-processor page, the ZDR contracts, the audit query, and the customer preference controls — either loses the deal or eats the cost of manual audit-response work per prospect. A platform that can answer it precisely turns the question from a deal-blocker into a differentiator.

Organizational requirements

Legal owns sub-processor management and vendor-contract enforcement. Security owns the redaction rules and the audit-store integrity. Platform Engineering owns the model registry gates and the customer-preference surface. Product owns the customer-facing sub-processor page and preference UX. The Autonomy Council reviews new model vendor additions before Platform Engineering integrates them, because the sub-processor list is a customer-visible artifact.

Cost and investment

The redaction pipeline is a moderate engineering investment (a service in front of every external model call, with a rules engine and reversible-tokenization layer). Vendor enterprise tiers cost more than consumer-tier APIs but the delta is small relative to enterprise deal size. Audit infrastructure is a variant of standard event-log storage. Customer-preference UX is one screen in the tenant admin panel. The largest cost is discipline — refusing to route through consumer-tier APIs even when they are cheaper for a given capability.

Risks and safeguards

The failure modes are subtle:

Relationship to the wider plan

This section closes the operational loop opened by this chapter’s IP subsection: IP posture is about liability for output; customer-data controls are about the input path. Together they are the two halves of "what does the platform tell an enterprise customer about how their data is handled when an agent runs against it." The sub-processor obligation ties into the regulatory posture subsection because most regulated frameworks (GDPR, HIPAA, SR 11-7 in banking) treat model vendors as sub-processors or downstream service providers with enumerated obligations.

Supporting material

Anthropic Zero Data Retention (R364), OpenAI Enterprise / API data controls (R365), Google Vertex AI data-governance and no-log agreement (R366), AWS Bedrock data-governance guidance (R367), Azure OpenAI data-handling and data-loss-prevention (R368), GDPR Article 28 on processors and sub-processors (R369), and Salesforce Einstein Trust Layer as a peer example of the pattern formalized as product (R370).

Viewpoint

Regulation is now an input to platform architecture, not a review gate applied afterward. The EU AI Act’s classification of AI systems into unacceptable, high, limited, and minimal risk determines what documentation, testing, transparency, human oversight, and post-market monitoring the platform must supply. US financial and health-sector rules (SR 11-7 for model risk in banking, HIPAA’s requirements for PHI, SEC AI-related disclosure guidance for public companies) add sector-specific obligations. A platform that cannot produce the required artifacts on demand does not become "compliant later"; it becomes unusable for the workloads that most need it.

Implication

The orchestration platform must produce, per capability, the documentation and evidence the EU AI Act requires of "providers" and "deployers" of high-risk systems (technical documentation, data-governance records, human-oversight design, transparency disclosures, post-market monitoring, and incident reporting). The evidence chain (see Appendix N) becomes the substrate for these artifacts: they are not written by hand; they are derived from the evidence the platform already produces. The autonomy tier assigned to a capability must reflect its regulatory classification — a capability that touches a high-risk EU AI Act use case cannot sit at T4 without the human-oversight provisions the Act requires.

Concrete proposal

Each capability in the registry carries a regulatory-posture record: EU AI Act risk class, applicable sector rules (SR 11-7, HIPAA, GDPR Article 22, SOX where relevant), the human-oversight design that satisfies each rule, the transparency artifact the platform will publish, and the post-market monitoring signals it will emit. The Autonomy Council reviews regulatory posture as part of every tier promotion. When the EU AI Act’s implementing regulations change, the Council reviews the affected capability classes on the next quarterly cadence, and the platform’s regulatory-posture reports are regenerated from the evidence chain rather than manually updated.

A peer example. JPMorgan Chase’s LLM Suite deployment to 200,000+ employees was scoped explicitly against the bank’s existing SR 11-7 model risk management program (R361). Every model use case is inventoried, validated, and periodically re-reviewed. This is the enterprise pattern the regulatory-posture record generalizes: the artifacts already exist for traditional risk models; the AI-native platform derives them from the evidence chain rather than reinventing model risk management.

Open questions

Viewpoint

Continuous model routing and evaluation. Quality, latency, cost, safety, and policy evidence improve each subsequent routing decision.

Model quality and vendor behavior are not static. Engineers compare notes about which model is converging on a task this week. Specialized products already split work among models, and some capabilities use small or specialized models for narrow tasks. A long-term platform may route work automatically, but that intelligence should not be assumed to work reliably today.

Near term, engineers may need choice and an explicit budget. One near-term option is a wallet model: a monthly allowance, visibility into usage, controls to disable an account or model, and a process for requesting more. The wallet is not obviously the durable answer, however: a complex task may legitimately need an expensive model, and a developer might also burn forty dollars editing a README without realizing it.

The most important behavioral point was feedback speed. A month-end report arrives too late for the developer to remember the task that caused the spend. A near-real-time burn meter or post-task notice can connect cost to behavior while the decision is still salient. The system can suggest a cheaper model for similar work without pretending cost is the only objective.

Concrete proposal Provide task-level cost and quality telemetry, immediate burn-rate feedback, recommended model choices, configurable budgets, and a path to request additional capacity. Introduce automatic routing only where evaluations support it.

Business driver and expected gain Model costs can grow quickly while quality varies by task and over time. Teams need to spend enough to converge on valuable work without using premium reasoning indiscriminately or learning about waste at month end.

Organizational requirements FinOps, platform, security, and engineering leadership need common cost attribution and exception policies. Engineers need guidance that explains trade-offs without treating spend alone as misuse.

Cost and investment The proposal requires usage aggregation across vendors, task attribution, dashboards, budgets, routing evaluation, and commercial management. It may also reduce waste and strengthen vendor negotiations.

Risks and safeguards Hard caps can interrupt valuable work, cheap-model routing can increase retries, and cost metrics can discourage experimentation. Optimize cost per verified outcome, allow justified exceptions, and compare convergence rather than token price alone.

Relationship to the wider plan Task characterization, model choice, execution evidence, cost feedback, and evaluation form one loop. Near-term human choice can gradually give way to routing policies where evidence shows that automation is reliable.

Supporting material DORA documents changing patterns of adoption, verification, and outcomes; model and agent providers document routing, evaluation, and tool-design practices. The wallet and immediate burn-rate interface remain design proposals. See [R1, R2, R11].

Viewpoint

This document has evidenced the downside of AI-assisted development with numbers: McKinsey on the size of the existing tech-debt estate, Liu et al. on the persistence of AI-introduced debt, METR on the gap between perceived and measured productivity. The upside deserves the same discipline. It is cautious but not absent.

The strongest positive evidence is a set of randomised trials rather than a survey. Cui et al. ran three of them across Microsoft, Accenture and an anonymous Fortune 100 company — 4,867 developers in total — and measured a 26% increase in completed tasks for developers given an AI coding assistant, with the larger gains going to the less experienced (R406). It is the cleanest causal result in the field and it needs one caveat stated immediately: it tests coding assistance, not the architecture this document proposes. Completed tasks are also not verified outcomes, which is the whole distinction the book turns on.

Set that against the skeptical anchor and the picture is neither flattering nor damning. METR measured 19% longer task time — but on 16 maintainers across 246 tasks, using early-2025 tooling, and the 2026 follow-up carries selection bias (R354). A 4,867-developer trial and a 16-developer study are not the same kind of evidence, and the honest reading is that assistance helps on task throughput while the question this document actually asks — what happens to verified outcomes per unit of attention — remains unmeasured by either.

Practitioner self-report sits in between and should be weighted as what it is. Stack Overflow’s 2025 survey reports 69% of agent users claiming higher productivity, and, from 31,476 responses, 45% saying that debugging AI-generated code takes them more time (R407). The second number is the more interesting one, and it is self-reported friction rather than a measured increase — which is exactly the gap METR was built to find.

DORA’s 2024–2025 research finds teams with strong underlying practices see genuine throughput and stability improvements under AI adoption — the amplifier effect works in both directions, and a team already operating with continuous delivery, small batch sizes, trunk-based development, and disciplined observability captures throughput gains without paying them back in incident rate (R1, R2, R339). Meta’s CodeCompose report at FSE 2024 (R359) is the largest peer-reviewed example of a well-instrumented enterprise deployment: 30,000+ engineers, careful separation of suggestion acceptance from productivity, and outcomes measured against system-level rather than individual metrics.

The honest range

For a well-executed AI-native platform program targeting classes of change the platform is designed to accelerate — bounded features, routine bug fixes, dependency and framework upgrades, test generation, documentation drift, and Class-1/Class-3 ambient work — the honest range for cost per verified outcome reduction is 20-40 % on the change classes the program covers, sustained over an eighteen-month window. Anything above that range should be treated as marketing until measured against DORA four keys and a debt-delta on the touched surface. Anything below suggests the program’s foundations are weaker than assumed and the platform is being asked to compensate for organizational latency it cannot remove.

Implication

The upside is a curve, not a constant. Returns are logarithmic as more change classes are covered: the first two ambient classes deliver a large step; the tenth delivers a smaller marginal gain. The curve plateaus when comprehension debt catches up — a team that ships more per unit of human attention without ever measuring comprehension will eventually hit the cognitive-debt wall described in the debt chapter, at which point the marginal gain flattens or reverses. The upside compounds only when the debt chapter is executed in parallel, not skipped.

Viewpoint

Every major model vendor has by now (2024-2026) issued 90-day end-of-life notices on capability tiers that many enterprise deployments actively depended on. Model versions get deprecated, capability tiers get restructured, pricing bands shift, and the underlying "same" model behaves subtly differently across releases. A platform that assumes the current model tier will still exist in twelve months is a platform that will spend a quarter of its next year in unplanned migration.

Implication and portability contract

The orchestration platform must ship a portability contract that survives vendor churn:

Relationship to the wider plan

Vendor substitution is not a procurement exercise; it is an architectural property that the model router, the evaluation harness, the capability registry, and the Autonomy Council jointly enforce. Treating it as a procurement fire-drill is what turns a 30-day EoL notice into a 90-day panic.

Viewpoint

Substitution readiness (the previous section) is defensive: the platform can survive if a vendor deprecates a tier. Multi- vendor as an active strategy is offensive: the platform routes production traffic across more than one frontier vendor in steady state, for two reasons that the substitution-only story does not address.

Frontier-model quality wavers day to day. Any team operating at scale on frontier models observes it: the same prompt, the same temperature, the same evaluation suite produces meaningfully different results across days as vendors ship silent updates, retrain, adjust safety filters, rotate model cards, or shift the default routing behind their own "same" model endpoint. The variance is real and irregular. A platform that treats any single frontier vendor as authoritative for a capability inherits that vendor’s day-to-day quality jitter as its own product quality. A platform that routes across two or three qualified alternates and grades every output against the evaluation harness in-flight can detect the jitter, route around it, and treat the variance as an operational signal rather than an unexplained regression that customers are the first to notice.

Frontier-vendor availability is not enterprise-tier. The public status pages of the frontier model vendors record visible degradations, elevated error rates, capacity throttles, and full outages on a cadence that the enterprise systems these agents support do not. An enterprise SLO of 99.9% for the agent-served capability cannot be built on top of a single vendor whose own observed availability sits below that threshold. Multi-source routing with automated failover is the standard mechanism for composing an application-level SLO out of upstream services that individually miss it — the same discipline applies to model vendors.

Concrete proposal

The model router treats the multi-vendor set as a pool with health, not as a primary-plus-backup. Concretely:

The router is one of the platform components most under-invested in the industry’s current AI-development pitches. Vendors sell a single-vendor experience; the platform buys optionality by insisting on more than one, actively, in production.

Cost, quota, and business-continuity implications

Multi-vendor active routing carries a real cost. Vendor A’s committed-use discount is only earned on the traffic actually routed to Vendor A; splitting 60/40 means less committed discount per vendor than a 100/0 split. The platform accepts that cost as the price of the availability and quality-jitter insurance the pool provides. The Finance conversation frames it that way explicitly — the incremental spend is compared to the expected annualised cost of an SLO breach and the reputational cost of a customer-visible outage that the platform could have avoided.

Contractual quotas across vendors are managed together — the platform buys just enough capacity from each vendor to survive the failure of any single one, not enough at each to run independently. This is the standard availability-engineering trade-off applied to a new class of upstream service.

Relationship to the wider plan

The multi-vendor active routing pattern depends on the model router, the per-capability evaluation harness, the workspace broker’s placement policy, and the Autonomy Council’s willingness to defend the incremental cost as an architectural property. It compounds with the substitution readiness discipline (previous section) — every vendor in the active pool is by definition already a qualified substitute — and with the governed egress posture in the customer-data section: adding a vendor to the pool requires the sub-processor and ZDR contract terms already covered.

Viewpoint

The field moves too quickly for an organization to settle permanently on one vendor, model, workflow, or technique. A team or set of accountable individuals needs to scan what is emerging, work with vendors, run trials, involve developers, and determine whether a new capability changes the SDLC. Backend, UI, review, and operations work may each favor different tools.

Engineers are often hungry to learn and willing to experiment. Brown bags, internal talks, newsletters, hackathons, early-access cohorts, alpha testers, and communities of practice are not peripheral communications. They are the social system through which useful practices spread and weak practices are challenged.

There also needs to be a budget and a measurement method for trying new things. “Everything in this presentation may be out of date tomorrow” was partly a joke, but it points to a real design principle: the platform should be adaptable, and the operating model should continuously evaluate both technology and its effect on developer behavior.

Concrete proposal Establish a continuous technology-evaluation function with early-access cohorts, reproducible workflow benchmarks, communities of practice, vendor engagement, and a governed path from experiment to supported platform capability.

Business driver and expected gain Models, tools, and effective working techniques change faster than traditional annual platform planning. Without a deliberate evaluation and adoption function, the organization either freezes too early or chases novelty without evidence.

Organizational requirements A small accountable team should coordinate trials while practitioners across disciplines contribute evidence. Leaders must fund experiments, recognize contributors, and retire practices that no longer work.

Cost and investment Recurring spend includes evaluation environments, licenses, model usage, vendor pilots, enablement, and staff time. This is an option-preservation budget rather than a one-time transformation program.

Risks and safeguards The organization may chase novelty, create tool sprawl, or let central standards lag behind practitioners. Use time-boxed trials, published evidence, adoption thresholds, security review, and explicit retirement decisions.

Relationship to the wider plan Evaluation connects new-tool trials with cost, quality, security, workflow metrics, paved-road updates, and progressive authority. Communities of practice turn local discoveries into reusable organizational capability.

Supporting material Current research and vendor engineering material emphasize evaluation and the dependence of AI outcomes on the surrounding system. Prior internal programs illustrate practical mechanisms for cohorts, brown bags, and bounded experiments. See [R1, R2, R11] and Appendix E.

The economic argument above connects to a first-class discipline of managing three kinds of debt — technical, comprehension, and cognitive — developed in full in the debt chapter. Read that part as the third pillar of this chapter’s economic argument rather than as a separate topic.

Metrics tied to this chapter (definitions consolidated in Appendix T):

Seven metrics; two of them (SAR response time, bypass attempts) are hard constraints rather than trend indicators.

Viewpoint

Ward Cunningham introduced the technical-debt metaphor in 1992 to describe the deliberate trade-off of shipping something rough-but- working with the intention to refactor later (R344). Four decades of practice have shown that most tech debt is not deliberate — it is accretion: dependencies age, patterns fall out of favour, the team that owned the code moves on, the why behind a decision is forgotten even when the what is still running. AI does not change this dynamic. It changes the rate.

An engineer writing code at 100 lines per hour and understanding all of it accretes debt at one rate. An engineer supervising four agents that each produce 400 lines per hour of plausible-looking code accretes debt at a fundamentally different rate — even when the code is correct today, because the engineer’s understanding of what got written and why has not scaled with the output. Speed without understanding is technical debt. Faster speed without understanding is faster debt.

This is not an alarmist claim. It is a call to make the trade-off visible.

The literature that has appeared since generative AI arrived in mainstream development distinguishes three related but distinct kinds of debt. The debt-management program has to address all three:

Technical debt is what static analysis sees. Comprehension debt is what a single reviewer notices when they try to explain a change and can’t. Cognitive debt is what an on-call engineer discovers at 3am when the person who "wrote" (delegated) the code is not on the team, and neither is anyone else who understands the intent.

These three are the debts the literature names, and all three sit downstream of a decision to build the thing at all. There is a fourth one upstream — intent debt, work in flight nobody can explain the reason for — which arrives by the same mechanism and is covered in the requirements and discovery chapter. The measurement apparatus in this chapter deliberately stops at the three that attach to code.

Enterprises already carry more tech debt than is comfortable, before AI amplifies anything:

The AI-native platform inherits this baseline. Any argument about how much faster agents make development has to reconcile with how much of the resulting work is being spent servicing debt rather than adding value.

Direct longitudinal measurement of AI-created debt has arrived. It supports the argument this chapter makes rather than contradicts it:

The Liu et al. figure — 22.7 % of AI-introduced issues persisting to the latest version — is the single number to put in front of a skeptic. It refutes the "the churn washes out" argument and matches the Cunningham "debt" metaphor precisely: it accrues interest.

A peer example. Meta’s CodeCompose report at FSE 2024 (R359) is instructive at scale: with 30,000+ engineers instrumented, they had to distinguish suggestion acceptance from productivity because a suggestion accepted and then rewritten is not the same as work saved. Enterprise measurement of AI-native platforms should treat acceptance as a leading indicator only and reserve outcome credit for the DORA four keys and the debt-delta on the touched surface.

First, AI can make debt legible. Static analysis, dependency graphs, and inline documentation-drift detection have existed for years, but they emit findings faster than any team can triage. An agent that reads the codebase alongside its git history, incident ledger, and change classification can produce a debt inventory that is prioritized by risk, blast radius, and cost of remediation — not a JSON dump. See Appendix R for the R.25 pattern.

Second, AI can execute controlled remediation at scale. The industry has two well-tested patterns for making high-risk change manageable, both defined before generative AI existed:

Both patterns require a discipline the platform must enforce: every change carries evidence. The evidence chain (Appendix N) does the enforcement — a Mikado leaf or a Strangler migration hop only advances when the acceptance and regression suites for the affected surface stay green.

The four DORA keys measure delivery outcomes. Tech-debt work is often defended with prose ("this makes the codebase healthier") but should be defended with the same measures as feature work:

An ambient DORA-attribution agent (Class 3, see the ambient-agents chapter) can attribute changes in these metrics to specific debt campaigns and feed the attribution back into the next campaign’s priority ranking. This closes the loop so debt work is measured by outcome, not by lines of code changed.

The orchestration platform must treat comprehension as an evidence type, not an assumption. Every substantial agent-generated change should carry:

Comprehension is a first-class output of the platform. Without it, "the tests pass" becomes the only understanding anyone has of what just shipped — and that is the definition of accumulated debt.

Ship four capabilities as a coordinated bundle:

Business driver and expected gain

If the pre-AI baseline is 20–40 % of tech-estate value spent on debt, the worst outcome of AI adoption is that number climbing because agent-generated code accretes faster than the team’s comprehension does. The best outcome is that number falling meaningfully because AI-assisted Mikado, Strangler, and drift correction execute campaigns that would have been too expensive to staff manually. Neither outcome is automatic; the difference is whether comprehension is measured and whether debt work is prioritized by evidence.

Organizational requirements

Platform Engineering owns the debt inventory agent, the Mikado / Strangler harnesses, and the comprehension-record contract. Engineering leadership includes debt outcomes in the same review as feature delivery. The Autonomy Council authorizes tier promotions for debt-remediation agents. Each service owning team accepts or rejects the decision packets the debt agent opens; ignoring the packets is a signal that either the packet quality is low (agent tuning problem) or the team’s capacity is exhausted (an org problem).

Cost and investment

The debt inventory agent is a Class 3 ambient agent (continuous low burn). The Mikado / Strangler harnesses are one-time platform investment plus per-campaign compute — comparable to running a short-lived batch agent per migration. The comprehension record adds per-PR model spend on the order of one extra 30k-token model call per PR; at ~$0.30 per call and enterprise PR volumes this is a rounding error against the value of catching a comprehension-mismatch before merge.

Risks and safeguards

The paradox is real: the same platform that lets agents remove debt at scale lets agents create debt at scale. Liu et al.'s 22.7 % persistence figure (R353) says the risk is not theoretical. Safeguards:

Debt-management feedback loop

The five-stage loop below is the same shape as the other LR flows in this document; the pastel positions carry the same meaning.

Debt-management feedback loop. Measurement feeds a prioritized inventory; controlled changes are executed via evidence-gated Mikado or Strangler harnesses; outcomes are attributed via DORA and the debt inventory updates for the next cycle.

Two worked examples

A peer case study. Airbnb migrated ~3,500 React Enzyme test files to React Testing Library in six weeks using LLM-driven per-file transformation with the test suite as the gate (R360). A manual estimate was 18+ months. The published case study is the closest public analogue to the SDK-deprecation example that follows: bounded scope, per-file evidence, Mikado-style backtracking when a transformation failed.

Relationship to the wider plan

Debt is the negative-space measurement of every claim this document makes about net-verified outcomes (see the one-page argument). More verified outcomes per unit of human attention is a durable gain only if the outcomes do not accrete an equal amount of unwatched debt. The comprehension record is the bridge: it forces the platform to produce, per change, evidence that humans still understand what got done.

Supporting material

Cunningham’s original 1992 debt metaphor essay (R344), McKinsey’s 2020 tech-debt research (R345), Stripe’s 2018 Developer Coefficient study (R346), Fowler on Strangler Fig (R334), Ellnestam and Brolund on the Mikado Method (R347), and DORA’s cross-year performance research (R1, R2, R339).

Direct AI-created-debt evidence: Liu et al. (2026) large-scale empirical study of AI-authored commits (R353); Osmani on comprehension debt with the Anthropic RCT on skill formation (R350); Storey on cognitive debt and Naur’s "Programming as Theory Building" (R351, R352); METR on experienced-developer productivity perception vs. measurement (R354); MIT Sloan Review on the productivity trap (R355).

Metrics tied to this chapter (definitions consolidated in Appendix T):

Eight metrics; this chapter is the section of the platform whose measurement discipline most directly determines whether the platform is delivering net-verified-outcome or externalising debt onto the organisation.

Viewpoint

The platform affects product managers, architects, principal engineers, software engineers, QA, security, and operations. The useful point is not a prediction of job elimination. As the cost of execution falls, the boundaries between disciplines become more permeable.

A product manager may create and test a working prototype from a specification, and an agent may do the reading that used to define their week — nine hundred support tickets summarised before lunch (the requirements and discovery chapter). What does not move is the customer conversation or the choice, which is where the role’s judgment was always concentrated. An engineer can use AI to understand more business context. A software engineer spends more time on constraints, evaluation, complex failures, and maintainability. Principal engineers and architects spend more time designing platforms, interfaces, guardrails, migration paths, and organizational mechanisms. Quality work does not disappear; it becomes a lifecycle responsibility supported by agents and evidence.

Implications

AI lowers the cost of execution; it does not remove the need for judgment. Deep expertise may become more valuable because it is applied to higher-consequence decisions. This topic should probably occupy one short portion of the presentation: it motivates why the platform must serve everyone who participates in software creation, not only a person typing code in an IDE.

Concrete proposal Give product, design, engineering, architecture, QA, security, and operations governed access to shared context, prototypes, environments, and evidence while preserving named ownership for consequential decisions.

Business driver and expected gain AI reduces the cost of producing artifacts across role boundaries. Teams can shorten handoffs when product, design, engineering, architecture, and operations share executable evidence rather than exchanging only documents and tickets.

Organizational requirements Leaders must clarify decision rights, update role expectations, invest in AI and systems literacy, and create joint working practices. Career frameworks should reward judgment, learning, and platform contribution as well as direct implementation.

Cost and investment The main investment is enablement, change management, shared tooling, and protected learning time. Shorter handoffs may reduce coordination cost, but broader access increases governance and support needs.

Risks and safeguards Role ambiguity, deskilling, uneven adoption, and unreviewed production work can follow. Keep accountability explicit, preserve deep expertise, use progressive access, and evaluate teams on verified outcomes rather than apparent activity.

Relationship to the wider plan The platform should expose the same governed knowledge, environments, capabilities, and evidence to different roles while preserving ownership of consequential decisions. Role flexibility increases the need for clear authority rather than reducing it.

Supporting material Industry research shows broad AI use alongside increased verification demands. The conclusion that deep expertise moves toward higher-consequence decisions remains a reasoned projection. See [R1–R3].

Viewpoint

Using AI to build software and building products for a world in which people increasingly begin from a prompt are different concerns. Adding AI features inside an application is not enough. Enterprise products also need to make trusted capabilities easy for agents and customer-created workflows to discover and compose.

A worked scenario: a user gives natural-language instructions to store a document, request an electronic signature, and then classify or extract information — potentially initiated from an external AI workspace rather than the product’s own destination UI. A second path begins inside the product and lets customers safely assemble a tailored workflow without writing traditional code. The strategic point is reach: the same trusted capability should be available on every surface a user or agent might reasonably start from.

Software itself becomes easier to reproduce, so data, trust, permissions, governance, ecosystem position, and reusable capabilities become more defensible. Being available where users orchestrate work may protect relevance and expand the surface on which a product is chosen.

Viewpoint

An AI-native platform succeeds or fails on adoption long before it succeeds or fails on architecture. A platform that ships every capability described in this document but is used by only the alpha cohort has produced no net-verified outcomes. Change management is therefore not a rollout task attached to launch; it is a permanent product capability of the orchestration platform, staffed and measured accordingly.

Implication

Resistance to AI-assisted work is legitimate, informed by past tooling promises, and unevenly distributed across teams and career stages. Senior engineers may worry about accountability without authorship; mid-level engineers may worry about role compression; junior engineers may worry about learning pathways collapsing. Each of these concerns has a specific answer that the platform must provide as a product, not as a memo:

Concrete proposal

Fund a platform adoption team as a peer of Platform Engineering, with product management, developer advocacy, learning design, and research capacity. Its measures are activation rate per capability, time to first verified outcome, satisfaction and trust deltas by role and tenure, and — critically — the rate at which teams decline to adopt a capability along with the reason. Declines are inputs to platform roadmap, not signs of resistance to be overcome.

Establish a communities of practice cadence: alpha cohorts for new capabilities, monthly show-and-tell across teams, an internal "decisions we changed our mind on" log, and protected experimentation time for teams that want to trial a new pattern before it becomes paved.

Publish a transition contract per role affected: what changes in day-to-day work, what new skills are supported, what does not change (compensation band, career ladder rung, review criteria), and what the escalation path is when the contract is not being honored. The absence of an explicit contract is what turns AI adoption into a rumor-driven exercise.

Open questions

Viewpoint

An orchestration platform that raises the ceiling on verified outcomes per engineer also raises the floor on what an engineer must know to be effective. The market for the resulting role is not the same market the enterprise has been hiring from. Talent strategy is a first-order platform concern because a platform without engineers who can operate it well is a compliance liability.

Implication

Three specific pressures need explicit organizational answers, not optimistic slogans:

Concrete proposal

Refactor the engineering career ladder within one calendar cycle to name the orchestration mode explicitly. Add or revise rung descriptions to include: leading design of a T3 or T4 capability; contributing to the platform evaluation corpus; sitting on the Autonomy Council for a capability class; operating as a review or operations orchestrator across N teams. Promotion committees receive training on how to evaluate evidence-chain artifacts as first-class career evidence.

Create at least two named specialty tracks — model evaluation and routing and agent security — with their own compensation bands and hiring pipelines. Treat these tracks the way security engineering and site reliability engineering are treated today: distinct disciplines that partner with generalist engineering rather than sitting inside it.

Redesign the internship, new-grad, and mid-career programs to teach orchestration from the start. The exercise "here is a spec, produce a change and its evidence chain" replaces "here is a spec, write the code." Interns who complete such programs are the leading indicator of whether the pipeline is intact.

Open questions

Viewpoint

Alongside the role permeability discussed earlier, agentic development lowers a second boundary that has quietly shaped how engineering organisations are staffed: the tech-stack silo. An engineer who has spent a decade in backend Go can now, with agent assistance, contribute a plausible React component to a UI they would previously not have opened. A platform engineer can spin up a Python data pipeline for a POC in an afternoon that would have required a data engineer’s calendar last year. A team that needs to evaluate a new SDK — a database driver, an observability client, a payments library — can produce a working spike in a language they do not maintain, without a full onboarding cycle for the person doing the work.

As a feature. This is workforce flexibility of a kind the industry has not previously had. Cross-stack contribution reduces the coordination tax on small changes that would otherwise stall waiting for the "right" team. POCs that would have been non-starters — because the cost of a senior engineer learning enough of an unfamiliar SDK to evaluate it exceeded the value of the evaluation — now become tractable. A generalist tier of engineer, augmented by agents, can move fluidly across the parts of the system that most organisations have historically had to staff as separate specialties.

Both look equally secure from standing height, and the difference is invisible from there. Confident enough to merge, not deep enough to catch what should not have been merged.

As a concern. The same fluency lowers the cost of producing work in an unfamiliar stack without lowering the cost of evaluating it. An engineer flexing muscle they have not built deeply is at exactly the kind of comprehension risk this document addresses in the debt chapter — able to sign off on generated code that looks right, unable to explain why an edge case is or is not handled, unable to recognise idiomatic-versus-anti-pattern choices in the target language. The failure mode is shallow-familiar: confident enough to merge, not deep enough to catch what should not have been merged.

Concrete proposal

Treat cross-stack contribution as a governed capability, not a free-for-all. Specifically:

Business driver

Cross-stack fluency is the single largest source of organisational flexibility the platform delivers. It is also the single most under-discussed source of comprehension debt. Naming both sides, and building the routing mechanism above, lets the organisation capture the flexibility without paying the debt as an unstated externality.

Relationship to the wider plan

Directly extends role permeability (this Part), depends on the comprehension record and reviewer self-report gap mechanisms (the debt chapter), and interacts with the maturity matrix (the maturity-journey chapter) — the cross-stack question is a specific case of the more general question about which cells the platform is ready to shade in colour for which teams.

Metrics tied to this chapter (definitions consolidated in Appendix T):

Six metrics; each maps to a this chapter claim about how the organisation changes as the platform matures.

Four properties of agent traffic break assumptions that held for human traffic.

Volume and fan-out. One human question becomes twenty tool calls across four products. Rate limits sized for a person clicking are sized wrong, and a retry storm from one misconfigured agent looks identical to an attack.

Composition. Your output becomes an input to a synthesis you never see, alongside data from systems with different permission models. The audience of that synthesis is not the audience of your response.

No presentation layer. A person reading a result page understands that a count is approximate and a snippet is truncated. A model reads the number and asserts it. Every field is an output, including the ones that were previously decoration.

Your descriptions are prompt content. Tool names, parameter descriptions, and error strings get read by a model as instructions. They are a quality surface and an injection surface at once, and they are written by whoever last edited the schema.

An engineer asks an agent to investigate a production incident. The agent searches incident reports, source repositories, customer tickets, and deployment records. The engineer can read some of these, the incident-response service can read others, and the approved model route may process only a subset. A service account with broad read access makes that integration easy to demonstrate, and easy to use to hand the engineer an answer derived from records they could never open.

Point authorization asks whether a principal may perform an action on a known resource. Set authorization asks which resources satisfy both the query and the policy, under a defined view of identity, relationships, attributes, and time. The second question governs titles, snippets, citations, facets, counts, ordering, and whether a continuation page exists. Those are observable outputs even when no document body is returned.

Two different questions. Point authorization clears one known resource and is what most product permission models were built to answer. Set authorization constrains discovery, ranking, and every observable output before anything leaves the trusted boundary — and it is the question an agent asks constantly.

Separate the permission to discover an object, to read its content, to process it with a particular model or integration, and to execute an action against it. These need not become four public roles, but they do need an explicit mapping. A principal who can list file names may still be barred from retrieving text for a model; a capability link may grant access to a known object without granting broad search discovery.

The consequence for a product organisation is uncomfortable and worth stating plainly. A search endpoint is a security boundary. A retrieval service is a policy execution engine whether or not anyone calls it one, and its contract has to describe both what the caller may learn and how missing or stale authorization information changes the answer (R377, R378).

Start with what the product exposes, because every later decision inherits it. A contract, a claim, a study deviation, or an incident is rarely one file. It has identity, relationships, a lifecycle, provenance, and actions, and a product that exposes only files pushes that modelling work onto every agent developer who then does it differently.

Expose the entity. A deviation with a study identifier, site, status, severity, owner, and evidence files supports a question like "how many open deviations at this site" that counting files with similar names cannot answer honestly. Make explicit whether the entity, its individual fields, its attachments, and its derived summaries have distinct release rules — they usually do, and the common mistake is letting the least sensitive one set the audience.

This is the durable version of a discipline enterprise content platforms have carried for decades: typed records with controlled attributes, lifecycle states with approvals, renditions tied to their originals, and federation across repositories. The opportunity is not inventing those semantics but making them reachable without a six-week integration.

An agent needs an attributable runtime identity even when acting for a person. Preserve the human or service sponsor, the agent identity, the application or client identity, the task or charter, the session, the intended audience, the permitted tools, and an expiry. An unattended workflow gets explicitly provisioned service authority with an owner and a review date — never a recycled employee session, and never a shared all-powerful integration user that erases attribution.

Effective authority is the intersection of every hop, never the union. A tool being available, an OAuth scope being granted, and a resource permission existing answer three different questions, and all three have to be satisfied at the moment of execution.

A child agent may narrow authority; it may not accumulate the union of unrelated parent grants. Purpose is part of the decision and cannot come from the model — bind it to an approved workflow or a trusted assignment and check that the requested action fits it. Token exchange supplies the actor and delegation concepts for carrying this across services, while attenuation, revocation, and inter-service trust remain deployment decisions; exchanging a token does not invalidate the original (R384).

MCP is where most products will meet this in practice, and the division is clean. Transport authorization establishes who is calling the server. Business authorization establishes what that caller may do, and the protocol has no opinion on whether this principal may summarise this contract. The current specification requires audience-bound token handling and its security guidance rejects token passthrough and addresses confused-deputy risk; pin the protocol versions you support and verify actual server behaviour rather than assuming it (R10, R385).

Three enforcement habits separate a product that survives this from one that demos well:

Reading a document that instructs the agent to export another file creates no authority to export it. That sentence is the whole of prompt-injection defence at the authorization layer, and it holds only if tool policy lives outside the model’s persuasion.

Most enterprise products support content shared beyond one customer’s boundary — external counsel in a deal folder, a supplier in a sourcing workspace, a CRO working on a sponsor’s study. Legitimate cross-organisation access is a first-class case rather than an isolation exception, and it is where tenant-shaped thinking fails first.

Consider counsel invited into a deal folder who also holds an expiring link to a supplier-owned contract. Their agent may legitimately compare authorized clauses across both, while the manufacturer’s internal pricing file stays out of reach. If the resulting comparison is saved into a broadly shared workspace, the audience of that destination needs checking independently of what the agent was allowed to read.

Each owner domain stays authoritative for its own resources. The broker combines only authorized evidence and checks the destination audience separately, because the right to read three sources is not the right to publish their synthesis.

Four rules make this tractable. Carry owner domain, stable object identifier, version, grant path, classification, and processing obligations on every source. Keep direct collaboration, group-derived access, and link-based access distinguishable, and never infer a permanent searchable grant from a link that resolved once. Declare the score-combination policy, deduplication, and candidate allocation when merging across domains, and let each domain’s freshness and failure status survive into the combined response — one unavailable domain reduces coverage and does not license a fall back to a stale external copy. Redact link secrets from prompts, logs, and any provenance shown to a viewer who lacks the underlying access.

For an inseparable synthesis, the default audience is the intersection of recipients permitted to receive every included source, further constrained by processing and export policy. Where the output needs a wider audience, produce an approved release or regenerate from eligible sources.

Everything above is invisible to the person integrating your product. What they experience is a set of promises that either hold or waste their week, and the difference between an ecosystem product and an API with an MCP wrapper is mostly here.

Publish a capability ledger that distinguishes announced from enabled from verified. An announced control is not a safeguard, and a feature enabled in one tenant is not enabled in theirs. State what is generally available, what requires enablement, what is in preview, and what the tenant administrator can confirm for themselves. Nothing erodes trust faster than a security property that turned out to be a roadmap item.

Ship a conformance suite the customer can run against their own tenant. Correctness claims that only you can verify are marketing. The suite that proves your contract internally is the one that should be published, with the expected decisions for a small reference corpus.

Give three worked examples, not thirty endpoints — a delegated read, an unattended service workflow, and a consequential write — each showing the expected failures and the audit fields they produce. Integrators copy the first example that runs, so make the first example the safe one.

Treat tool schemas as an API with a version and a deprecation policy. A renamed parameter breaks agents that were working yesterday, and unlike a human developer, the caller will not read a changelog. Publish deprecation windows and keep old contracts working through them.

Design errors for a machine that will retry. Deterministic error codes, a stated retry policy, idempotency keys on every mutating operation, cursors that survive concurrent change, and rate limits documented in terms of agent fan-out rather than requests per user. An ambiguous 500 becomes a retry storm.

Write tool descriptions as if a model will act on them, because one will. Say what the tool does, what it will refuse, and what its arguments mean in the product’s own vocabulary. Then treat the same text as an injection surface: descriptions are read into a context window alongside untrusted content, and a description that says "always call this first" is an instruction you shipped.

Decide whether you are selling retrieval or answers. If the product returns evidence, the consuming agent owns the synthesis and its audience. If the product returns an answer, you own the disclosure contract for a synthesis you generated, including whose permissions it reflected at the moment it was produced. Both are legitimate products; conflating them is how a retrieval API acquires liabilities nobody priced.

Publish time to safe first integration and defend it. The interval from a developer’s first call to a working, correctly authorized, audited integration is the adoption metric that matters, and it is the one a competitor with a worse permission model will beat you on until you measure it.

Everything to this point is what the caller sees and what the integrator signs up to. The rest of the chapter is the machinery that makes those promises true, and most of it is retrieval engineering — useful when the product’s answer is assembled from a search over material with mixed permissions, skippable if it is not.

Three models answer three different questions, and each carries a different retrieval cost.

Roles remain useful for stable responsibilities — reviewer, investigator, administrator. They become unmanageable when every combination of project, region, customer, and sensitivity becomes its own role, which is a modelling failure rather than evidence that RBAC is finished. Use relationships to find plausible resources, roles to describe actions inside those relationships, and attributes to impose contextual constraints.

Write down the composition rule. Ordinary grants might combine by union while a tenant-wide prohibition overrides them — and no source system should be assumed to have deny-overrides semantics because it feels safer.

Attribute governance is authorization engineering, not data entry. An HR system supplies employment status, an identity provider supplies group membership, a case system supplies participation, a learning system attests training, device management supplies posture. Each attribute needs a named issuer, a subject identifier, a validity interval, a refresh mechanism, and a rule for what happens when it is missing.

The sharpest version of this problem is new. A user-editable tag should not grant regulated access because it resembles a trusted classification — and in an AI-enabled product, the entity writing tags is often a model. An agent that classifies a document as public and then cites that classification as authority to export it has laundered its own guess into a permission. Keep model-extracted suggestions in a different field from approved policy inputs, carry the extractor version and reviewer with the value, and require an independent path for any change that relaxes protection.

Let U be the corpus visible to the trusted service, A(p, a, d, c, v) the authorization decision for a principal, action, document, context, and policy version, and Q(q) the query’s matching set under its documented semantics. The eligible set is E = { d ∈ U : d ∈ Q(q) and A(p, a, d, c, v) permits }. The desired result is the highest-ranked k members of E.

That compact definition hides four independent promises, and products routinely ship having tested one of them:

Post-filtering is the common shortcut and it is safe without being correct. Suppose the global ranking is D1 through D6 and the caller may read D2, D5, and D6. Fetch the global top three, drop what is not permitted, and one result comes back. The authorized top three were D2, D5, and D6. Overfetching improves the odds; no fixed overfetch factor guarantees enough eligible results across arbitrary permission distributions (R379).

This asymmetry deserves its own pair of tests. A final authoritative check removes false permits from stale candidates. It cannot recover an allowed document that a stale prefilter already excluded. Revocation safety and grant freshness are separate properties with separate service-level objectives, and a product that measures only the first will quietly under-serve every user whose access was recently widened.

Two smaller traps sit alongside. Hybrid lexical and vector branches need equivalent eligibility constraints, because a safe vector branch does not compensate for an unsafe lexical one. And ranking features disclose: global popularity, click history, and private entity relationships can move visible scores. Decide which features may be reused across audiences, and accept that most products draw a documented practical boundary rather than promising that hidden records have no observable statistical effect.

The response contract should carry citations with source versions, coverage and freshness metadata, and count semantics labelled as exact, approximate, lower bound, or unavailable. A service that hits its deadline should not let partial retrieval become a confident claim that no evidence exists.

"Twenty investigations match this executive’s name" discloses something while the records stay hidden. A facet for "acquisition target" reveals a category. A date histogram reveals when an investigation started. Error messages, autocomplete, and the difference between an empty and a non-empty response belong in the same threat model.

Evaluate aggregates over the same authorized population as the corresponding results. Where discovery is permitted but reading is not, decide deliberately whether discovery also permits aggregation rather than inheriting the answer from whichever count field the search engine happens to expose.

A worked case shows how quickly this gets away from a product team. An agent asks how many customers reported a vulnerability. One customer filed twelve tickets, another filed one. Counting passages, tickets, or distinct customers gives three different answers, so the query has to define the business unit of counting before it filters and aggregates. If some tickets are unreadable, the honest answer is "distinct customers in the records available to this session" rather than an implied organisation-wide total.

Exactness is a claim about a named corpus, predicate, identity context, and snapshot. It is not a claim that every real-world record was indexed. Approximate counts still need permission filtering — prefixing a number with "about" removes precision, not disclosure. Where an aggregate is meant to expose more than its underlying records, that is a separate analytical product with its own release policy; minimum group sizes help, repeated differencing queries defeat naive suppression, and differential privacy is a managed budget for statistical release rather than a substitute for document authorization (R380).

Cursors deserve specific attention because they are the easiest way to hand back access that was removed. Bind a cursor to the principal, the policy revision, the query, and the permitted scope. When authorization changes mid-pagination, either restart or revalidate each page and disclose the changed coverage.

The workable architecture separates policy authority from optimised execution. A control plane owns policy definitions, trusted attributes, relationship semantics, versions, and change propagation. A retrieval plane consumes compiled projections and performs the residual checks. This is a separation of responsibility, not an instruction to create a microservice per box.

Stable authorization inputs are compiled into retrieval projections; volatile conditions stay as runtime checks. The compiler declares which predicates it enforces exactly, which become residual checks, and which it rejects — dropping one silently is the failure that ships, because it makes the query faster and the tests still pass. Content is authorized before it reaches a reranker or a model, and again at release, because the release audience is not always the retrieval principal.

Three execution strategies are all legitimate, and a product can support them under one contract rather than picking a religion. Search-first with batched checks suits small corpora or a high eligible fraction, keeps the authority boundary simple, and needs a bounded refill budget with honest partial coverage when access is sparse. Authorization-first obtains an eligible set or compact filter and searches inside it, which works for small scopes and compressible groups but can exceed query limits when it materialises millions of identifiers — object-listing cost depends heavily on the relationship model (R381). Integrated filtering pushes permissions or stable eligibility terms into the serving layer, avoiding network round trips at the price of a derived security representation that has to be compiled correctly and kept current.

Policy compilation is where the correctness risk concentrates. Partial evaluation substitutes the known principal and context into policy and leaves a residual predicate over documents; the technique is well documented, along with the limits of translating arbitrary policy into a target query language (R382). A compiler should declare which predicates it enforces exactly, turn the rest into residual checks, and reject what it cannot handle. Dropping a predicate silently is the failure that gets shipped, because it makes the query faster and the tests still pass.

Conservative over-inclusion inside a trusted boundary is acceptable when the final check blocks disclosure. Conservative under-inclusion costs completeness and has to be reported rather than absorbed.

A projection might store group identifiers on documents, ancestor references, relationship summaries, classification labels, or compressed access bitmaps. The inverse design stores accessible resource sets per principal or cohort. Neither orientation is universally cheaper — it depends on membership churn, hierarchy depth, sharing density, resource count, and query selectivity.

Expanding a large group onto every user-document pair makes reads cheap and makes one membership change expensive. Keeping group identifiers in the index avoids rewriting documents when someone leaves a group, and requires a fresh, bounded principal-group expansion on every query. Folder ancestry reduces duplicated inherited grants, and turns moves into important correctness cases.

Whichever way it goes, keep the source relationship and policy records authoritative and treat every index or bitmap as a replaceable projection with a declared schema, compiler version, source watermark, and rebuild procedure. Propagate by change events with ordering rules, idempotent application, tombstones, retries, and poison-event handling, then reconcile periodically to catch what the events missed.

One failure here is worth naming because each half looks healthy on its own dashboard: an index generation that contains new content and old permissions. Publish content and security projections behind a common activation barrier, use dual generations with a reversible pointer switch, and validate policy equivalence before activation.

The revocation deadline is the number a customer will ask for, and it needs two named endpoints: an authority event such as the committed removal of a collaboration, and a disclosure boundary such as the last permissible release of a newly requested passage. Instrument event detection, projection update, cache invalidation, regional propagation, and in-flight requests separately, because the slowest one is the answer.

The revocation deadline is only meaningful with both endpoints named. Each stage between them is instrumented separately, because the slowest one is the number you can actually commit to — and an average across them hides it. The overlay is the escape hatch for sensitive revocations that cannot wait for the projection.

A freshness token can require reads at least as recent as a policy mutation, and mature authorization systems expose exactly that (R378, R383). A token honoured by the authorization service does not synchronise a separate vector index — the application carries that requirement across both systems or it does not hold. Where the index lags, a fresh authoritative check protects reads while completeness suffers; for sensitive revocations, a small deny overlay or an epoch bump can block access before the projection catches up, provided the overlay itself is bounded, reliably delivered, and reconciled.

Embeddings, extracted text, thumbnails, summaries, metadata, semantic caches, and conversation history are derived from source material, and the change of format grants no new audience. This is the derived-representation policy inheritance from the foundations chapter, seen from the product side, where the derivations are a feature customers pay for.

Represent a derived artifact as an object with lineage. Where a summary inseparably combines sources A and B, the recipient needs authorization for both unless an approved transformation has produced a genuinely new releasable artifact. Where the material is separable, authorize each passage and recompute from the permitted subset — deleting an inaccessible citation leaves its influence in the prose.

A permissions-only change is the case that breaks naive pipelines. Re-embedding on content change is not enough when the bytes are identical and the audience moved. Shared chunks and deduplicated vectors need indirection to every source binding, or physical isolation where that is simpler; byte equality is not evidence that two tenants have the same rights.

Streaming introduces a race that no amount of policy fixes: emitted tokens cannot be recalled. High-risk workflows can buffer, verify at release, and cancel on a detected revocation; lower-risk workflows can run on bounded leases with stated semantics. Neither retracts what was legitimately disclosed a second before revocation, and a product should distinguish preventing future disclosure from promising retroactive erasure it cannot perform.

Cache keys carry the same burden. Include the authorization context or an equivalence identifier, the security domain, the action, resource and content versions, policy and membership epochs, the model route, and any query parameters that change results. A query-string cache hands one user’s answer to another; a per-user key alone still fails after a group removal. Cache decisions and content separately, and remember that logs, traces, and replay stores hold the evidence the user was trying to reach and need their own access controls.

The machinery above decides what may be disclosed. The three sections that follow are about running it — keeping the boundary honest under attack, under load, and under partial failure.

Deterministic authorization prevents disallowed reads and writes. Injection detection identifies suspicious content and triggers a configured response. Behavioural monitoring notices unusually broad or rapid activity that was individually permitted. Audit reconstructs what happened. Four jobs, and the recurring product mistake is letting the second one stand in for the first.

A detector cannot safely replace resource policy, and an alert raised after an export cannot undo the export. Design so the system stays safe when detection misses: a malicious document instructing an agent to summarise every HR file and mail it out is defeated by task scope, tool policy, and destination authorization, with the detector adding evidence rather than being the control.

Response authority needs its own blast-radius limits, which is easy to forget when the responder is itself an agent. Session termination, grant revocation, integration suspension, and quarantine are all reasonable; removing every collaboration in a customer’s tenant because an anomaly score moved is not. Measure the interval from a committed containment action to blocked future disclosure separately from detection latency and log-ingestion lag — they are three different numbers and only the first one bounds harm.

A point-check benchmark is not a retrieval benchmark. End-to-end latency includes identity resolution, relationship expansion, policy planning, search fan-out, candidate checks, reranking, generation, audit persistence, and retries. Measure warm and cold paths, sparse and dense access, large groups, deep hierarchies, tenant skew, and revocation bursts.

A first-order capacity estimate: candidate demand ≈ k / s, where s is the fraction of candidates that survive authorization. For k = 20 and s = 0.02, roughly a thousand candidates are needed, assuming survival is independent of relevance — which it frequently is not. Treat it as intuition for provisioning, not as a bound.

That sums to a 500 ms envelope before generation begins. Component p95 values do not compose into an end-to-end p95, so correlated traces have to validate the real distribution. A model call measured in seconds can still sit behind an authorization path that saturates under fan-out.

Isolation and fairness matter more than they did with human traffic. Derive tenant context from trusted credentials and authoritative ownership rather than a request parameter, partition indexes, caches, queues, and keys to the threat model, and enforce query scoping that callers cannot omit. Bound concurrency with per-tenant and per-agent limits, bulkheads around expensive relationship listings, adaptive candidate limits, and cancellation propagation — a retry storm must not consume the capacity that processes revocations.

Then there is the commercial model, which most product organisations discover late. Seat-based pricing assumes a human ceiling on consumption that agents remove, and a single enthusiastic customer integration can generate more retrieval load than a thousand interactive users. Meter what agents actually consume — calls, candidates examined, tokens processed, aggregate operations — attribute it to the sponsoring principal rather than the integration’s service account, and expose that attribution to the customer so their own budget owner can see it. Give expensive operations, exact counts in particular, their own opt-in budget and failure policy. A product that cannot attribute cost to a sponsor cannot let customers control it, and will eventually price the behaviour it wants to encourage.

Failing closed means preventing unauthorized disclosure. It does not mean turning every dependency outage into an empty result, and the difference is most of the perceived quality of an agent-facing product.

Audit records need the authenticated subject, the agent and application, the operation, a scoped query hash, policy and attribute versions, the security watermark, the decision and its reason category, source identifiers and versions, the model route, result coverage, and a trace identifier. Keep raw query text and secrets out by default, and restrict detailed deny reasons so that diagnostics do not become an oracle for whether an object exists.

Measure unauthorized disclosure as a security incident. Measure false denials, empty-result rates, authorized recall, and stale-grant exposure as quality problems with different owners and different release consequences. Track revocation propagation percentiles and the oldest outstanding security event rather than average indexing lag, which hides exactly the tail that matters.

Proving any of this needs a small exact reference corpus and an authoritative evaluator to compare candidate plans against. Include nested groups, multiple grant paths, folder moves, deleted relationships, expired links, unknown attributes, and cross-tenant identifiers, then run the same cases through search, listing, metadata queries, retrieval-augmented answers, counts, caches, and tool actions. Inject reordered and missing events, stalled replicas, lost cache invalidations, policy-version skew, and revocation between retrieval and release.

Regulated customers will ask a question the product organisation usually has not framed: which part of this is inside the validated boundary? Classify the use case first — exploratory assistance, draft generation, controlled decision support, or execution that affects a regulated record — because the obligations differ sharply across those four and the same feature can sit in any of them depending on how a customer wires it.

Record intended use, system boundary, source of truth, human responsibilities, and accepted failure behaviour. A retrieval assistant over approved procedures should bind evidence to approved document versions and effective dates, exclude superseded or draft material by policy, and keep reproducible provenance. Authorization testing does not substitute for use-case validation: a model can produce a wrong answer from perfectly authorized evidence.

AI systems break traditional change control because the parts that change are not all code. Track versions for the model, the prompt and configuration, the tool schema, the retrieval method, the policy compiler, the source schema, and the processing destination. A model substitution changes behaviour while every permission stays identical. Define which of those changes require requalification and which are covered by regression evidence, and keep rollback and incident review procedures that work when the regression is statistical rather than a stack trace.

Retention, access, and deletion are three separate obligations and agent products conflate them routinely. A record under legal hold must be preserved without granting its former readers continued access. A deletion request has to propagate to derived artifacts that no longer resemble the source. Where preservation and deletion obligations genuinely conflict, that is an explicit policy decision with a named owner — not something a cache-eviction schedule should settle by accident.

Four phases, sequenced by evidence rather than calendar.

Establish semantics. Take one retrieval journey with sensitive material and a clear owner. Define the point and set contracts, enumerate every disclosure surface it touches, and build an exact test corpus with expected decisions. Baseline current latency, permission-change lag, developer effort, and authorized relevance. The exit criterion is agreement on observable behaviour and a reproducible harness — not a design document.

Build the paved road. Provide a policy-aware retrieval adapter, a source-lineage envelope, delegated-call context, and an authorization-aware cache helper, integrated across one lexical and one vector path. Shadow the optimised plan against an authoritative reference on controlled workloads and investigate every disagreement before release. Shadow results stay internal.

Prove change and failure. Exercise group removal, link expiration, classification changes, large folder moves, and regional outages. Demonstrate the revocation deadline end to end, through caches and generated answers. Measure authorized recall under sparse access, and require a tested rollback and a durable owner before extending to another team.

Extend to business workflows. Add permission-aware aggregates, long-running agents, external integrations, and derived business entities once the contracts hold. Validate each new processing destination and action type, then publish migration guidance and compatibility tests so the next integration is routine engineering rather than another negotiation.

Three shortcuts should be rejected explicitly at the start, because each passes a demonstration and fails in production: broad crawler credentials standing in for end-user authority, post-generation redaction as the primary access control, and cached answers without source dependencies. Demonstrations rarely include conflicting roles or a revocation mid-flight.

Ownership splits across teams that do not usually share a roadmap. Identity and security own principal and policy semantics. Search owns eligible-set planning and authorized relevance. Content owners supply lineage and mutation ordering. The agent platform preserves delegation and tool contracts. SRE owns failure exercises and freshness observability. Product owns what an incomplete result is allowed to claim. A shared semantic contract and a conformance suite prevent fragmentation without requiring one central service to execute every check.

A product should answer these with contracts, tests, and production evidence. A prompt instructing an agent to respect permissions is useful guidance; the enforcement layer is what makes the instruction true.

Metrics tied to this chapter (definitions consolidated in Appendix T):

Nine metrics across four dimensions that fail independently: disclosure, freshness, usefulness, and adoption. A product can hold the first and lose the third — refusing everything is perfectly secure — which is why authorized recall belongs on the same dashboard as unauthorized disclosure.

The work-management system should hold durable intent, ownership, decisions, and status. It should not become a hidden orchestration engine. Agents need to read specifications, propose decomposition, link evidence, and update state through explicit APIs and events while the platform retains execution, identity, policy, and audit responsibilities.

Concrete proposal Define a spec-to-production object model that links signal, opportunity, outcome, specification, acceptance criteria, work item, change set, decision packet, test evidence, deployment, incident, and learning. Use webhooks or service hooks for event-driven transitions; scoped service identities for writes; idempotency keys and correlation IDs for every mutation; and state-machine rules that prevent an agent from declaring completion without the required evidence. Linear’s current agent model is instructive: the agent is a delegate while a person remains the assignee and owner. Azure DevOps similarly provides work-item, repository, build, release, service-hook, and MCP surfaces that can participate in the flow (R48–R54).

Spec-to-production evidence chain. A durable outcome contract accumulates decisions and proof from customer signal through production learning, with every stage depositing evidence into one locked chain. The two green stages are the upstream half (the requirements and discovery chapter); the amber path is rework; the green return runs from production learning back to the opportunity that proposed the work, not to the beginning.

Business driver and expected gain The gain is less translation loss between planning and delivery. Acceptance criteria become test inputs, implementation evidence returns to the work item, release status is derived rather than manually narrated, and incidents can point back to the decision and change lineage that produced them. Managers see flow and exceptions without demanding more status reporting from engineers.

Organizational requirements Product owns outcome and acceptance language; Engineering owns decomposition and technical evidence; the platform team owns integration contracts and identity; Security and Compliance define required approvals and retention; work-system administrators govern schemas without encoding product-specific logic into a central workflow.

Cost and investment Costs concentrate in schema governance, connectors, event delivery, reconciliation, and migration from free-text conventions. Avoid a single large workflow rollout. Start with read-only context and evidence links, then permit bounded writes after reliability and ownership are proven.

Risks and safeguards Risks include accidental reassignment, duplicate issues, misleading status, runaway decomposition, stale specifications, and cross-project data exposure. Safeguards include human ownership, explicit write scopes, preview-before-create for fan-out, rate limits, deduplication, optimistic concurrency, reversible transitions, field-level audit, and a reconciliation process for dropped or reordered events.

Relationship to the wider plan This is the durable-object side of the decision inbox. The work item becomes the stable join point for intent and evidence, while execution stays in agent workspaces and collaboration uses the appropriate protocol boundary.

Supporting material Appendix K defines the canonical objects, event flow, failure handling, and phased rollout.

the orchestrator chapter argues that agent execution belongs in isolated, identity-bound workspaces. The choice it does not make is where those workspaces run — and that choice is the difference between a vendor evaluation and a platform architecture.

Agent workspace and policy plane. One policy contract governs isolation, identity, evidence capture, and teardown regardless of where the workspace runs.

The orchestrator chapter's review-shift-left section states the position; this section names what the platform delivers to make that position real.

AI pull request review as an evidence-producing control. Findings are classified, measured, and returned to accountable human judgment.

The reviewable output of the platform is one decision packet per pull request, produced by the sequence and control tiers defined in Appendix I. The orchestrator chapter section Review shifts left but does not disappear covers why this matters and what the human role becomes; this section commits to what the platform must ship: a review service that assembles the context, runs the checks defined by the risk class, and writes a decision packet whose minimum fields (including SBOM, SLSA provenance, and model version pins) are enumerated in Appendix I. Movement between the T0–T4 tiers uses the canonical autonomy ladder in the glossary, so review, remediation, and operations all reason about authority in the same units.

Cross-references: the orchestrator chapter "Review shifts left but does not disappear" (rationale and human role); Appendix I (operating model, minimum decision packet, break-glass procedure, evaluation scorecard).

the orchestrator chapter argued that testing and operations become parallel agentic disciplines. This section names the evidence ladder that unifies them so the platform can reason about "safe to promote" in one vocabulary regardless of whether the change comes from an author, an agent, or an operational remediation.

The ladder — static and policy checks, hermetic unit tests, contract tests, integration tests against short-lived real dependencies, isolated end-to-end tests, security and resilience checks, deployment preview, canary or blue-green release, production health evaluation, and learning capture — is specified in Appendix N. Each stage emits machine-readable evidence with provenance. Promotion between stages uses the same autonomy tiers as review and remediation.

The vendor toolchain that supports each stage is well-covered: OpenTelemetry for signal vocabulary; Pact for consumer-driven contracts; Playwright for browser isolation; Testcontainers (Docker/AtomicJar) for known-state dependencies; Kubernetes with Argo Rollouts for incremental rollout and rollback (R55–R65). The platform’s contribution is not another test runner — it is the evidence chain that connects the outputs of these tools into one decision packet the release process can approve or reject.

Cross-references: the orchestrator chapter's sections on testing and operations (rationale, org design, cost); Appendix N (evidence ladder detail, operational autonomy tiers, scorecard); glossary for the canonical autonomy ladder shared with review.

The evidence ladder above is written in the vocabulary of backend service work, because that is where the automated forms are strongest. Applied unchanged to every discipline it produces a false result: a platform that either refuses to let UI work advance because the evidence does not reduce to a passing suite, or lets it advance on evidence that was never about the thing that matters.

User-interface work is the clearest stress test, and it strengthens the argument rather than breaking it. An agent can produce a large amount of genuine evidence for a UI change — screenshots, visual diffs against the previous state, interaction recordings, accessibility checks, design-system conformance, a browser and device matrix, performance measurements, user-flow results, a live preview to click through, and experiment data where the change is running behind a flag.

What none of that encodes is whether the interaction is confusing, whether the treatment communicates the product’s intent, or whether the result is simply wrong in a way a designer will recognise in a second and struggle to write down. Those judgments stay human, and the platform’s job is to put a person in front of the running artifact with the automated evidence already gathered, not to invent a score that makes the decision look decidable.

The forms differ by discipline, and each has a different automation ceiling:

This is why autonomy ceilings are set per task class rather than per agent. A dependency bump in a well-tested service can reach a high tier on evidence alone. A change to how a workflow feels cannot, and saying so is more useful than pretending a threshold exists.

Cheap exploration pays unusually well here. Asking for three materially different treatments that satisfy the same constraints costs little, and the automated checks run against all three. The human then chooses an experience instead of implementing candidates one at a time — which is the optionality argument from the orchestrator chapter, arriving in the discipline where it is easiest to see.

Metrics tied to this chapter (definitions consolidated in Appendix T):

Six metrics; each is developed further in Appendices I, J, K, and N of the reference operating models.

Viewpoint

Google SRE named toil as the category of work that is manual, repetitive, automatable, tactical, devoid of enduring value, and grows at least as fast as the service (SRE book, 2016). The SRE framing has been narrowly applied to production operations. AI-native platforms extend the same framing to every engineering-adjacent discipline. Most knowledge work carries a toil tax: dependencies that need bumping, runbooks that need updating, dashboards that need pruning, alerts that need calibrating, docs that drift, tests that grow flaky, spec templates that fall behind reality, retrospectives that never turn into action items.

Reactive AI (feature requests, bug fixes, PR review) reduces the per-item cost of visible work. Ambient AI reduces the volume of toil that visible work is dragged down by. The two together produce the compounding effect. An organization that only invests in reactive agents ships faster but continues to accumulate ambient debt; an organization that only invests in ambient agents keeps the house clean but does not ship faster. The platform argument requires both.

Implication

The orchestration platform must treat ambient agents as first-class, not as scripts-with-a-personality living in a corner of the org. That means: they use the same workspace broker, decision packet system, autonomy tiers, constitution mechanism, and evidence chain as reactive agents. Their governance is not a separate discipline; it is the same discipline applied to a different trigger model. Their cost is budgeted; their signal quality is measured; their sunset is planned.

The three axes of an ambient agent

Every ambient agent is characterized by three axes: what triggers it, what it does when triggered, and how it terminates.

The three axes of an ambient agent. Trigger, Action, and Termination combine to define an agent’s operating envelope. Governance is attached per-axis: trigger governance controls fan-out; action governance maps to the T0–T4 autonomy ladder; termination governance controls resource lifetime.

Two examples worth naming up front

These two agents look nothing alike operationally, but they run on the same platform primitives and are governed by the same constitution mechanism. That is the point.

A peer precedent. Google SRE named toil in 2016 as the class of work most amenable to automation, and paired it with the error-budget mechanism to keep the trade explicit (R357). Ambient agents are the AI-native generalization: they attack toil across security, docs, dependencies, and operations. The signal-to-noise budget defined for each ambient agent is the direct analogue of an error budget applied to interrupt-worthy output.

Relationship to the wider plan

This chapter is where the platform decisions from the previous chapters compound. Ambient agents depend on: the orchestration platform (Part One), organizational knowledge and MCP/A2A (the foundations chapter), constitution + residency + IP posture + regulation (the trust and governance chapter), roles and adoption (the organizational chapter), the reference operating models (the operating-models chapter). An organization that has not built out those foundations will find that ambient agents create more toil than they remove.

The categories below are not exhaustive; they are the eight classes most consequential for an AI-native enterprise. Each class carries a worked exemplar and points to the reference pattern in Appendix R.

Ambient agents use the same platform primitives as reactive agents. This section names how each primitive is applied under the ambient trigger model.

Agent workspaces. Ambient agents run in agent workspaces exactly like reactive agents (see Appendix J). The workspace class is chosen by trigger and action tier: an Observe-only scheduled agent may run in Explore class; an Apply-reversible fleet migration agent uses Change class; a T3 Apply-bounded remediation agent uses Remediation class. Isolation tier (I1–I5) is chosen by data sensitivity, not by "ambient vs reactive."

Standing service identity. An ambient agent typically has no per-task human sponsor. Its identity model is a standing service identity combined with a scoped authorization envelope and periodic Autonomy Council reauthorization. The identity is workload-authenticated (SPIFFE/SPIRE, cloud IAM role, or equivalent), carries a constitution reference, and is renewed on a cadence set by its tier (quarterly for T3, monthly for T4). Delegated user identity does not apply, because there is no user; the substitute is ownership identity — a named team or role that is accountable when the agent misbehaves.

Identity models compared. A reactive agent’s identity is derived from a present human; an ambient agent’s identity is derived from an owning team plus a standing workload identity plus a versioned constitution reference. Both compose down to the same task identity primitive.

Decision packets. Ambient agents emit decision packets whenever human judgment is needed (an unusual finding, a policy exception, a class-boundary question). The packet format is identical to a reactive agent’s; the difference is in the routing. A reactive agent’s packet routes to the requesting user; an ambient agent’s packet routes to the ownership identity of the agent’s capability. Route quality is a first-class metric — an ambient agent that consistently routes to the wrong owner is a governance failure that compounds.

Autonomy tier and constitution. Ambient agents obey the canonical T0–T4 ladder (glossary). Their constitution (Section 10.7) is where their governance lives: the constitution names the tier, the class boundaries, the signal-to-noise budget, the fan-out cap, the reauthorization cadence, and the sunset criteria. An ambient agent without a signed constitution runs at T0 only.

Evidence chain. Ambient agents attach to the same evidence chain (Appendix N) as reactive agents. Their outputs (a proposed dependency bump; an anomaly investigation; a runbook update) carry the same provenance, citation, and audit surface as human-initiated work. This is what makes ambient work auditable at scale — a fleet migration that touches 800 services is exactly as auditable as 800 hand-written PRs would have been.

MCP and A2A. Ambient agents are heavy users of MCP tools (read telemetry, browse repos, query the service catalog). Class-6 ecosystem-intelligence agents are among the earliest useful A2A consumers — they discover and delegate to third-party specialist agents (a model-eval agent published by a research collaborator; a CVE-analysis agent published by a security partner) more naturally than reactive agents do.

Cost telemetry. Every ambient agent reports its cost against its ownership identity, per invocation and per unit time. FinOps rolls up cost per ambient class, per capability, and per team, so the "silent army" cost creep failure mode is visible before it becomes material.