Which Shared Components Actually Unlock More Capability? Build a Capability Dependency Graph

A capability portfolio tells you what the platform should own.

It does not yet tell you what the platform should build first.

That is a different problem.

Suppose you want to add five new agent capabilities:

• repository migration planning,
• browser-based account reconciliation,
• incident diagnosis,
• autonomous research synthesis,
• schema-aware data repair.

You could build each capability independently.

That is often the obvious path.

It is also often the expensive path.

The five capabilities may depend on the same underlying primitives:

• reliable state capture,
• provenance,
• structured tool interfaces,
• sandboxed execution,
• verifier infrastructure,
• retrieval,
• policy enforcement,
• replay,
• scheduling,
• durable checkpoints.

If you build the shared primitive once, several capabilities may become cheaper to acquire.

But there is a catch.

A shared primitive can also become a shared failure domain.

If every production capability depends on one retrieval index, one verifier service, one browser pool, one policy engine, or one state-capture mechanism, then a defect in that component can degrade the entire portfolio at once.

So the problem is not simply:

Which shared component unlocks the most features?

The real problem is:

Which dependency investments create the most verified capability leverage without creating unacceptable correlated risk?

That is what a capability dependency graph is for.

The core rule for this post is:

Optimize shared primitives for verified portfolio leverage, then harden the dependencies whose failure would invalidate many competence claims at once.

The Search Problem: “What Should I Build First in an AI Agent Platform?”

Agent roadmaps are frequently organized as a list of features.

coding agent
browser agent
research agent
DevOps agent
analytics agent

That list hides the architecture.

The platform may actually look more like this:

                           provenance
                              |
                  ____________|____________
                 /            |            \
            state capture   replay      incident forensics
                 |            |            |
                 |            |            |
          _______|____________|____________|______
         /                |                |      \
   coding repair      browser action   research  DevOps
         \                |                |      /
          \_______________|________________|_____/
                          |
                    verification

The feature list says five products.

The dependency graph says a smaller set of shared primitives supports them.

That matters for investment.

It also matters for reliability.

Capabilities Are Not Independent Assets

Step 32 treated capabilities as portfolio assets with acquisition and carrying costs.

That is useful, but capabilities are rarely independent.

A capability may depend on:

model capability
+ tool support
+ state representation
+ retrieval
+ verifier
+ sandbox
+ authority policy
+ scheduler
+ provenance
+ release compatibility

Another capability may reuse seven of those ten pieces.

That means the marginal cost of the second capability may be far lower than the first.

Or far higher if one shared dependency is weak.

This is why feature-by-feature planning can misallocate engineering effort.

Model the Capability Graph Explicitly

A useful graph has at least two node classes:

Capability nodes
Primitive nodes

For example:

Capability: repository repair
    depends on
        repository snapshot
        code search
        sandbox
        patch application
        test verifier
        provenance

Capability: dependency upgrade
    depends on
        repository snapshot
        package metadata
        sandbox
        patch application
        test verifier
        provenance

Capability: incident repair
    depends on
        repository snapshot
        telemetry retrieval
        sandbox
        patch application
        test verifier
        provenance

Immediately, several shared primitives become visible.

repository snapshot
sandbox
patch application
test verifier
provenance

Those are platform investments.

A Minimal Graph Representation

The graph does not need to begin as a graph database.

Start with ordinary data structures.

from dataclasses import dataclass
from typing import Literal

NodeKind = Literal["capability", "primitive"]


@dataclass(frozen=True)
class DependencyNode:
    node_id: str
    kind: NodeKind
    version: str


@dataclass(frozen=True)
class DependencyEdge:
    parent_id: str
    dependency_id: str
    required: bool
    minimum_version: str | None
    evidence_ref: str

The important thing is not the storage technology.

The important thing is that dependencies become explicit and versioned.

Not Every Dependency Is the Same

A capability can depend on another component in different ways.

Useful dependency types include:

REQUIRED
OPTIONAL
PERFORMANCE
VERIFICATION
AUTHORITY
OBSERVABILITY
RECOVERY

These distinctions matter.

For example:

research synthesis
    REQUIRED retrieval
    REQUIRED citation extraction
    VERIFICATION source validation
    OBSERVABILITY provenance
    OPTIONAL specialist critic

If the critic fails, the capability may degrade.

If citation extraction fails, the capability may become unusable.

Those are different operational consequences.

Capability Dependency Graphs Are Directed

The edge direction matters.

capability
   ↓ depends on
primitive

For example:

browser purchase proposal
        ↓
DOM state capture
        ↓
browser session runtime

But the reverse is not true.

A browser runtime does not depend on the purchase-proposal capability.

This lets you calculate downstream impact.

The First Useful Query: What Does This Primitive Unlock?

For any primitive, ask:

which capabilities depend on it directly?
which capabilities depend on it transitively?
which authority levels depend on it?
which verifier paths depend on it?

Suppose sandbox_runtime_v4 supports:

repository repair
migration planning
package upgrades
schema migration
incident reproduction
capability acquisition

That is high capability leverage.

But leverage alone is not enough.

The Second Useful Query: What Breaks If This Primitive Fails?

Now reverse the perspective.

Suppose the same sandbox runtime fails.

sandbox runtime unavailable
        ↓
repository repair unavailable
migration planning limited
package upgrades unavailable
schema migration limited
incident reproduction degraded
capability acquisition blocked

That is correlated risk.

A platform primitive can be both:

high leverage
and
high blast radius

Those are often the components that deserve the most reliability investment.

Leverage Is Not Just Capability Count

A naïve metric might be:

leverage = number of downstream capabilities

That is too crude.

A primitive supporting ten rarely used low-value capabilities may matter less than one supporting two high-volume critical workflows.

A better representation is:

portfolio leverage
    ≈ downstream demand
    × capability value
    × dependency criticality
    × authority relevance

Do not pretend this is an exact formula.

The point is to make the relevant dimensions explicit.

Add Verification Leverage

Some primitives unlock capability because they let the model do something.

Other primitives unlock capability because they let the platform verify something.

That distinction is important.

Consider a deterministic test harness.

It may not improve generation at all.

But it can expand the usable competence envelope for:

repository repair
refactoring
dependency upgrades
schema migrations
performance optimization

because those capabilities can now be externally checked.

That is verifier leverage.

Step 32 already suggested building the verifier first when verification is the bottleneck.

The dependency graph makes that visible across the whole portfolio.

A Verifier Can Be a Portfolio Primitive

For example:

pytest verifier
    ↓
Python repair
Python refactoring
Python dependency upgrades
Python migration tasks

Or:

DOM postcondition verifier
    ↓
form filling
account updates
checkout workflows
browser navigation

Or:

citation/source verifier
    ↓
research summaries
market reports
fact extraction
policy analysis

When a verifier supports several capabilities, verifier reliability becomes portfolio reliability.

Competence Claims Depend on the Graph

Step 30 defined competence as evidence-backed reliability within a task regime.

That competence claim implicitly assumes the dependencies used during validation remain valid.

Suppose a capability was validated with:

retrieval_v8
verifier_v3
browser_runtime_v5
policy_v6

Then production silently changes to:

retrieval_v9
verifier_v3
browser_runtime_v5
policy_v6

The capability graph should make that dependency visible.

Otherwise the platform may accidentally treat historical evidence as transferable when a critical primitive changed.

Version Every Important Edge

A dependency edge should not merely say:

research_agent depends on retriever

It should be able to say something closer to:

research_agent_release_12
    requires retriever >= 8.2
    validated with retriever 8.4
    verifier requirement source_verifier >= 3.1

This matters for compatibility and replay.

Dependency Changes Can Invalidate Evidence

When a primitive changes, ask:

which competence claims were validated against the old version?

Then classify the change.

compatible
requires shadow validation
requires partial revalidation
requires full revalidation
invalidates competence claim

This is release engineering applied to dependency graphs.

High-Leverage Dependencies Deserve Stronger Change Control

If one primitive supports a large portion of the portfolio, its release policy should reflect that.

For example:

low-leverage helper
    → ordinary canary

shared verifier gateway
    → broad shadow comparison
       cohort validation
       rollback-ready release
       stricter promotion gate

Change control should scale with downstream impact.

Use Dependency Centrality Carefully

Graph theory gives you several notions of centrality.

You may calculate:

• degree centrality,
• betweenness centrality,
• reachability,
• weighted downstream count.

These can be useful.

But do not let graph mathematics replace operational meaning.

A node with high graph centrality is not automatically a high-value investment.

It may be:

• easy to replace,
• low risk,
• rarely exercised,
• backed by excellent fallback capacity.

The metric is evidence, not the decision.

A Better Primitive Record

A primitive should carry more than an identifier.

from dataclasses import dataclass


@dataclass(frozen=True)
class PrimitiveProfile:
    primitive_id: str
    version: str
    downstream_capabilities: tuple[str, ...]
    critical_downstream_count: int
    fallback_available: bool
    verifier_role: bool
    authority_role: bool
    replay_role: bool
    observed_failure_rate: float | None
    maintenance_cost: float | None
    change_frequency: float | None

Again, do not obsess over exact numeric scoring initially.

Make the architecture visible first.

Dependency Classes Matter for Failure Propagation

A failure can propagate through the graph in different ways.

Hard failure

primitive unavailable
    ↓
capability unavailable

Quality degradation

retrieval quality drops
    ↓
evidence quality drops
    ↓
false-success risk rises

Verification degradation

verifier weakens
    ↓
PASS becomes less trustworthy
    ↓
competence evidence invalidates

Authority degradation

approval/fencing gateway unhealthy
    ↓
consequential commit authority removed

Those are different propagation paths.

Correlated Failure Is the Hidden Cost of Reuse

Software engineering correctly encourages reuse.

But reuse concentrates dependence.

If twelve capabilities share one primitive, then a single defect can affect twelve capabilities.

That does not mean reuse is bad.

It means reuse must be paired with failure-domain design.

The goal is not:

minimize shared components

It is:

maximize useful reuse
while bounding correlated failure

Example: One Retriever for Everything

Imagine one retrieval service powers:

coding context
research evidence
incident logs
browser knowledge
policy lookup
memory recall

That looks efficient.

Then a ranking regression occurs.

Now every subsystem sees degraded evidence.

The platform may experience:

worse patches
worse research
worse incident diagnosis
worse browser choices
worse policy decisions
worse memory selection

Infrastructure may still be healthy.

This is exactly the kind of correlated behavioral drift Step 23 was designed to detect.

The dependency graph tells you why the drift is correlated.

Sometimes Duplication Is a Reliability Feature

Not all duplication is waste.

For critical shared primitives, independent implementations may reduce correlated risk.

For example:

primary source verifier
secondary deterministic checker

or:

primary model provider
fallback provider

or:

central policy evaluator
local deterministic guardrails

The important question is whether the alternatives share the same failure mode.

Two wrappers around the same dependency are not independent redundancy.

Independence Must Be Real

Suppose you use two verifiers.

Verifier A → same foundation model
Verifier B → same foundation model

They may fail together.

That is correlated redundancy.

A stronger design might be:

Verifier A → deterministic tests
Verifier B → static analysis
Verifier C → model-based semantic review

Different mechanisms create different failure surfaces.

Dependency Graphs Should Include External Systems

Do not stop at your own code.

Capabilities may depend on:

model provider
browser provider
cloud region
vector database
GitHub
payment API
email API
identity provider
package registry
DNS
external data source

These are real dependencies.

If they matter to competence or authority, they belong in the graph.

Include Human Dependencies Too

A capability may depend on a human approval queue.

For example:

production schema mutation
    ↓
qualified DBA approval

That human role is part of the capability dependency graph.

So are:

• escalation queues,
• security review,
• domain expertise,
• legal approval,
• operations approval.

If the queue becomes unavailable, the capability changes state.

Human Review Can Be a Bottleneck Primitive

Suppose several high-risk capabilities require the same specialist reviewer group.

production deploy
payment correction
access-control change
incident rollback

Then human review capacity is a shared platform dependency.

Step 29 treated human attention as schedulable capacity.

The dependency graph shows which portfolio capabilities depend on it.

Graph the Authority Path Separately

It is useful to distinguish:

capability dependency graph

from:

authority dependency graph

For example:

repository patch proposal
    depends on model + repo state + patch generator

repository patch commit
    additionally depends on approval policy + verifier + fenced commit gateway

The generation capability may remain available while commit authority is unavailable.

That distinction prevents unnecessary full outages.

Graph Verification Paths Separately Too

A capability might have several verifier layers:

syntax check
unit tests
integration tests
security scan
postcondition check

The capability may require all of them for a particular authority level.

This gives you a verification dependency graph.

That graph is often more useful than a single verifier=true flag.

A Capability Can Have Multiple Operating Modes

Suppose a browser agent normally supports:

read
propose
submit

If the mutation verifier fails, the capability may degrade to:

read
propose

The dependency graph should support conditional capability modes.

submit requires mutation_verifier
propose does not

This makes graceful degradation much cleaner.

Capability Mode as a Graph Query

Given current dependency health, ask:

what is the maximum safe authority mode currently available?

For example:

def max_authority(capability, health, policy):
    for authority in reversed(policy.allowed_authorities):
        required = policy.dependencies_for(capability, authority)
        if all(health[d].usable for d in required):
            return authority
    return "UNAVAILABLE"

This connects the dependency graph directly to runtime authority.

Dependency Health Should Affect Admission

Step 21 introduced global admission control.

The scheduler should not admit work that cannot complete under current dependency health.

For example:

request requires browser mutation
mutation verifier unavailable

Possible scheduler decision:

DEFER

or:

DOWNGRADE_TO_PROPOSAL

rather than admitting the run and discovering the missing dependency fifteen minutes later.

Graph-Aware Backpressure

Backpressure can also follow dependency edges.

Suppose the verifier queue saturates.

Then capabilities that depend heavily on that verifier should reduce upstream generation.

verifier pressure
    ↓
capability scheduler
    ↓
reduce candidate fan-out
reduce speculative branches
queue low-priority work

The dependency graph tells the scheduler where to propagate pressure.

The Graph Can Improve Budget Scheduling

Step 16 allocated compute dynamically.

The dependency graph adds another signal.

If several branches depend on the same expensive primitive, the scheduler can recognize shared cost.

For example:

branch A → retrieval snapshot X
branch B → retrieval snapshot X
branch C → retrieval snapshot X

The runtime may coalesce the shared dependency work rather than paying three times.

Shared Work Can Be Cached More Safely

Dependency identity helps caching.

A cache key can include:

primitive version
input artifact hash
environment version
policy version

This reduces accidental reuse across incompatible contexts.

It also makes cached outputs replayable.

Dependency Graphs Expose Platform Multipliers

Some primitives have unusually high option value.

Common examples include:

State capture

Better state capture improves:

coding
browser automation
DevOps
incident forensics
replay
verification

Provenance

Better provenance improves:

replay
incident investigation
release validation
competence evidence
capability acquisition
audit

Sandboxing

Better sandboxing improves:

coding
browser simulation
capability acquisition
migration testing
incident reproduction

Verifier infrastructure

Better verification improves almost every authority-bearing capability.

These are platform multipliers.

But Multipliers Can Become Monocultures

A primitive that unlocks everything can also fail everything.

That is the architecture tension.

shared primitive
    ↓
high leverage
    ↓
high concentration
    ↓
high correlated risk

The answer is not automatically fragmentation.

The answer is to design explicit resilience around high-concentration primitives.

Measure Concentration Risk

Useful concentration signals include:

percentage of production capabilities depending on primitive
percentage of critical authority paths depending on primitive
percentage of verifier paths depending on primitive
percentage of revenue/workload volume depending on primitive
percentage of SLO budget exposed to primitive failure

These are more meaningful than raw node degree alone.

A Simple Concentration Record

@dataclass(frozen=True)
class ConcentrationProfile:
    primitive_id: str
    production_capability_share: float
    critical_authority_share: float
    verifier_path_share: float
    workload_volume_share: float
    slo_exposure_share: float

Do not treat the numbers as perfect risk probabilities.

Treat them as evidence for architectural review.

Failure Injection Should Follow the Graph

Step 22 introduced failure containment.

The dependency graph gives you a systematic way to choose failure-injection tests.

For each high-impact primitive:

fail it
slow it
corrupt its output
return stale output
return partially valid output
make it disagree with backup

Then measure downstream behavior.

Do Not Test Only Hard Outages

Hard outages are easy to detect.

Silent semantic degradation is often worse.

For a retriever:

service remains 200 OK
ranking quality degrades

For a verifier:

service remains available
false PASS rises

For state capture:

snapshot succeeds
but misses a relevant file

These failures can contaminate multiple capabilities simultaneously.

Shared Dependencies Need Behavioral SLOs

Infrastructure SLOs are not enough.

A retriever can be available but useless.

A verifier can be fast but permissive.

A browser runtime can be healthy but capture the wrong DOM state.

So critical shared primitives need behavioral SLOs too.

Examples:

retrieval usefulness
verifier false-pass ceiling
state-capture completeness
sandbox isolation integrity
provenance completeness
replay completeness

Primitive SLOs Roll Up Into Capability SLOs

This lets you reason about reliability hierarchically.

primitive SLOs
      ↓
capability SLOs
      ↓
portfolio SLOs

But be careful.

You cannot generally multiply component success rates and claim the result is system reliability.

Dependencies interact.

Use observed end-to-end verified outcomes as the final authority.

Keep End-to-End Verification Stronger Than Graph Inference

The graph may predict:

all dependencies healthy

Yet the capability can still fail.

The graph is an explanatory and planning model.

It is not a substitute for end-to-end verification.

Use the Graph to Prioritize Platform Investment

Suppose you have three possible infrastructure projects:

A: improve sandbox startup latency
B: build stronger repository state snapshots
C: add another specialist critic

The dependency graph shows:

A supports 4 capabilities
B supports 11 capabilities
C supports 1 capability

That is useful.

Then Step 28’s reliability economics adds:

expected reliability gain
engineering effort
risk reduction
maintenance cost

Now the investment decision is far better grounded.

Shared Infrastructure Has Option Value

A primitive may be valuable even before all downstream capabilities exist.

For example, durable provenance might enable future:

incident replay
scientific evaluation
regulatory audit
capability learning
cross-run optimization

That is option value.

But option value should not become an excuse for speculative platform building.

Require plausible downstream demand.

Avoid Architecture Astronautics

A capability graph can tempt teams into building a perfect universal platform before real workloads exist.

Do not.

Start with observed capability demand.

Then identify repeated dependencies.

Then extract shared primitives.

real workloads
    ↓
repeated mechanisms
    ↓
shared primitive

not:

imagined universal platform
    ↓
hope capabilities appear later

Extraction Should Follow Evidence

A good threshold for extracting a shared primitive is not simply “used twice.”

Ask:

is behavior sufficiently similar?
is lifecycle sufficiently similar?
is failure handling sufficiently similar?
is authority semantics sufficiently similar?

Two superficially similar mechanisms may deserve separate implementations.

Beware False Reuse

For example:

coding retrieval
research retrieval

Both are called retrieval.

But coding retrieval may optimize for:

symbol locality
dependency edges
repository freshness
exact file versions

Research retrieval may optimize for:

source authority
recency
source diversity
citation traceability

Forcing them into one universal abstraction may create worse architecture.

Reuse should be semantic, not cosmetic.

Primitive Boundaries Should Reflect Failure Boundaries

If two workloads have very different failure modes, consider separate primitives or separate policy layers.

For example:

read-only browser inspection
financial browser mutation

They may share the low-level browser driver.

But they should not necessarily share:

credentials
authority gateway
mutation verifier
queue

Shared implementation does not require shared failure domain.

Bulkheads Belong in the Graph

Step 22 introduced bulkheads.

The graph should encode isolation boundaries.

browser_pool_readonly
browser_pool_mutating

or:

research_retrieval_pool
incident_retrieval_pool

Even when the underlying software is similar, separate resource pools can prevent cascade.

Dependency Graphs Help Design Bulkheads

If several critical capabilities share one resource pool, ask whether they should.

For example:

incident response
background research

Both use browser sessions.

But incident response may deserve reserved capacity.

The graph makes the contention relationship visible.

Shared Dependencies Affect Scheduling Fairness

Step 21’s global scheduler can become graph-aware.

Suppose one capability requires:

GPU + browser + verifier

while another requires:

CPU + retrieval

The scheduler should understand the dependency resource vector rather than treating both as generic jobs.

This reduces head-of-line blocking and resource fragmentation.

Dependency Graphs Can Predict Admission Feasibility

Before a run starts, ask:

are all required critical dependencies available?
are reserved verifier resources available?
is required human approval capacity available?
is the authority gateway healthy?

If not, defer or downgrade immediately.

That is much cheaper than discovering infeasibility midway through a run.

Graph the Expected Verification Reserve

A capability should carry expected verification demand.

For example:

repository repair
    test verifier: 2-5 minutes
    static analysis: 30 seconds
    security scan: optional

The scheduler can reserve that capacity before spending all resources on generation.

This connects directly to Step 16’s protected verification reserve.

Dependency Failures Can Change Search Policy

Suppose the primary semantic verifier becomes degraded.

The platform might respond by:

reducing search width
increasing deterministic checks
requiring human escalation
blocking high-authority outputs

The dependency graph tells the control plane which policies are affected.

Track Dependency Provenance Per Run

Every run should record the actual primitive versions used.

run_123
    model = m42
    retriever = r8.4
    verifier = v3.2
    sandbox = s5
    policy = p12

That lets Step 25 replay reconstruct the execution accurately.

It also lets Step 26 incident forensics answer:

Which downstream failures correlate with this primitive version?

Blast Radius Queries Become Powerful

Suppose verifier_v3.2 is found to be permissive.

The graph can answer:

which capabilities used verifier_v3.2?
which production runs depended on it?
which competence claims were validated with it?
which releases promoted based on its evidence?
which authority decisions assumed its strength?

That is a real blast-radius analysis.

This Is Where Provenance and Architecture Meet

The dependency graph describes structural relationships.

Provenance records historical execution relationships.

Together:

structural dependency graph
        +
run provenance graph
        ↓
actual impact analysis

This is much stronger than either graph alone.

Structural Dependency vs Runtime Dependency

A capability may declare:

depends on retriever A or B

But a specific run used:

retriever B

The structural graph tells you possibility.

The runtime provenance tells you actuality.

Keep them separate.

Capability Dependencies Can Be Conditional

For example:

small repository repair
    no semantic index required

large repository repair
    semantic index required

The dependency graph should support predicates.

@dataclass(frozen=True)
class ConditionalDependency:
    capability_id: str
    dependency_id: str
    condition: str

The condition may eventually become structured policy rather than free text.

Avoid Hiding Policy in the Graph

The graph should not become an opaque policy engine.

Keep distinct layers:

dependency facts
policy decisions
runtime evidence

For example:

Fact:
capability requires verifier X for authority A4

Policy:
A4 forbidden when verifier X degraded

Evidence:
verifier X currently DEGRADED

That separation improves auditability.

The Graph Should Be Versioned

Capability dependencies evolve.

Record graph versions.

graph_version_2026_08_09_01

A production run can then reference:

dependency_graph_version

This helps replay old scheduler and authority decisions.

Diff the Graph During Releases

When a behavioral release changes dependencies, generate a graph diff.

For example:

ADDED:
repository_repair -> semantic_retriever_v9

REMOVED:
repository_repair -> lexical_retriever_v4

CHANGED:
test_verifier minimum version 4.1 -> 4.3

This is far more informative than “agent version bumped.”

Dependency Diffs Should Affect Release Gates

A release that changes a high-centrality primitive should require more evidence than a leaf-only change.

Possible rule:

if changed primitive downstream critical share > threshold:
    require expanded shadow evaluation
    require cohort replay
    require rollback drill

Keep thresholds versioned and external to the candidate release.

Shared Dependencies Create Hidden Coupling

You may think two agent capabilities are independent because they have separate code paths.

But they may share:

same model endpoint
same retrieval index
same policy store
same database
same verifier gateway
same browser provider
same queue

That is operational coupling.

The dependency graph surfaces it.

Hidden Coupling Explains Correlated Incidents

Suppose coding and research agents begin failing at the same time.

Without the graph, teams inspect two products separately.

With the graph, you may immediately see:

coding_agent ─────┐
                  ├── retriever_cluster_2
research_agent ───┘

That shortens incident localization dramatically.

Add Failure-Domain Metadata

A useful primitive record can include failure domain.

provider
region
cluster
queue
credential scope
data source
model family

Then you can detect apparent redundancy that is actually co-located.

Example: False Provider Redundancy

You might have:

Model endpoint A
Model endpoint B

but both run:

same model family
same cloud region
same account quota
same network path

That is weaker redundancy than it looks.

The graph should represent shared failure-domain metadata.

Shared Verifiers Need Extra Scrutiny

A shared verifier is particularly dangerous because it defines what the platform believes is success.

If one verifier becomes permissive, many capabilities can simultaneously appear healthy while becoming worse.

That is why verifier dependency centrality deserves special treatment.

Build Independent Gold Checks for Central Verifiers

For highly central verifiers, maintain independent reference cases.

gold PASS cases
gold FAIL cases
adversarial false-PASS cases
boundary cases

Run them independently of ordinary production traffic.

This is a central-dependency health check.

Central Verifiers May Need Diverse Mechanisms

For example:

coding verifier stack
    deterministic tests
    static analysis
    type checker
    semantic review

Do not let one model-based critic become the sole definition of correctness for the entire coding portfolio.

Shared State Capture Is Another Critical Primitive

If all agents make decisions from captured state, then state capture quality controls the entire platform.

A stale or partial snapshot can create:

wrong routing
wrong planning
wrong tool actions
wrong verification
wrong replay

This makes state capture a high-leverage, high-risk primitive.

State Identity Should Flow Through the Graph

A run should know:

capability used state_snapshot S42

and every downstream candidate, decision, and verifier result should bind to that snapshot or a known descendant.

This reduces TOCTOU ambiguity.

Provenance Is Often More Valuable Than Another Agent

Teams frequently invest in another specialist agent before investing in provenance.

But provenance may improve:

replay
incident diagnosis
competence evidence
release safety
drift analysis
capability learning

The dependency graph makes this leverage explicit.

This is exactly the kind of platform multiplier Step 32’s portfolio model should surface.

Shared Platform Primitives Can Reduce Prompt Complexity

A good primitive can move work out of prompts.

For example:

prompt says:
"remember to check repository state"

is weaker than:

runtime guarantees repository snapshot identity

Similarly:

prompt says:
"do not perform unauthorized actions"

is weaker than:

authority gateway blocks unauthorized mutations

Shared infrastructure can simplify agent reasoning.

The Best Dependency Is Often Deterministic

When a shared primitive can be deterministic, that is often valuable.

Examples:

schema validation
state hashing
policy enforcement
idempotency checks
fencing
rate limiting
resource accounting
provenance linking

These mechanisms should not be delegated to model reasoning unless necessary.

Do Not Build a Model for Everything

The dependency graph should expose places where ordinary software can replace model calls.

Suppose five capabilities each ask a model to classify file type.

If the rule is deterministic, extract it.

five model calls
    ↓
one deterministic primitive

That improves cost, reproducibility, and correlated correctness.

But Deterministic Primitives Can Still Be Wrong

A deterministic shared component can produce perfectly repeatable errors.

That can be worse because the failure propagates consistently.

So deterministic does not mean infallible.

It means easier to specify, test, replay, and reason about.

Dependency Testing Needs Contract Tests

Each primitive should have contracts.

For example:

state capture contract
    every referenced artifact has immutable identity
    snapshot completeness policy explicit
    stale state detectable

or:

verifier contract
    result binds exact candidate hash
    UNKNOWN supported
    missing evidence cannot become PASS

or:

authority gateway contract
    stale approval rejected
    fencing epoch enforced
    idempotency key required

These contracts reduce hidden coupling.

Contract Tests Belong at Dependency Boundaries

When one primitive changes, dependent capabilities should not need to know implementation details.

They should rely on contracts.

This is ordinary software architecture applied to agent platforms.

Compatibility Must Be Directional

A capability built against verifier v4 may work with verifier v5.

Verifier v5 may not work with an older capability release that assumes different evidence semantics.

Compatibility is directional.

Step 24 already established this for behavioral releases.

The dependency graph makes the direction explicit across shared primitives.

Shared Primitive Releases Need Their Own Canaries

Do not only canary top-level agent releases.

A central primitive may deserve its own rollout:

primitive shadow
primitive canary
limited downstream cohorts
general rollout

Then top-level capabilities can inherit tested infrastructure rather than all discovering the regression simultaneously.

Dependency-Aware Shadowing

Suppose retriever v9 is being tested.

You can shadow the same production queries through:

retriever v8
retriever v9

then compare downstream verified outcomes.

Do not judge only retrieval similarity.

Ask whether downstream decisions improve.

Measure Primitive Value Downstream

The right question is not:

did retriever recall improve?

It is also:

did verified capability success improve?
did false success change?
did latency change?
did cost change?

A primitive exists to support outcomes.

The Graph Makes Attribution Easier

If one primitive changes and several capabilities improve, that is useful evidence.

If several primitives change simultaneously, attribution becomes harder.

This reinforces Step 24’s rule:

Change one behavioral axis at a time when feasible.

Capability Graphs Help Decompose Platform Cost

You can attribute shared infrastructure cost back to capabilities.

For example:

retriever cost
sandbox cost
verifier cost
browser pool cost

Then estimate:

capability marginal cost
shared platform cost
portfolio carrying cost

This makes Step 32’s portfolio economics more realistic.

Shared Cost Allocation Does Not Need Accounting Perfection

The point is not finance-grade allocation.

The point is to detect obvious architectural distortions.

For example:

rare capability consumes 40% of shared verifier compute

That is strategically relevant.

Graph the Human Cost Too

A capability may consume:

reviewer minutes
incident responder time
manual fallback time
approval queue capacity

These are dependencies and costs.

If several capabilities depend on the same specialist humans, that may justify better automation—or deliberate capacity limits.

Capability Dependencies Change the Portfolio Ranking

Suppose capability A is mediocre in isolation.

But building A requires a verifier primitive that also unlocks B, C, and D.

Then A’s project may have hidden platform option value.

Conversely, capability E may look valuable but require an expensive one-off primitive no other capability uses.

The graph changes the investment decision.

Evaluate Projects as Bundles of Capabilities and Primitives

Instead of asking:

Should we build capability A?

ask:

What primitives does A require?
What else do those primitives unlock?
What new correlated risk do they create?
What lifecycle cost do they add?

That is a better architectural question.

A Simple Portfolio-Leverage View

@dataclass(frozen=True)
class PrimitiveInvestmentCandidate:
    primitive_id: str
    unlocks: tuple[str, ...]
    improves: tuple[str, ...]
    critical_dependents: tuple[str, ...]
    estimated_effort: float
    maintenance_burden: float
    concentration_risk: str
    fallback_quality: str

This is enough to begin structured review.

Avoid a Single Leverage Score

It is tempting to compute:

leverage_score = value / effort

Do not let that erase hard concerns.

A primitive that unlocks many capabilities but creates an unbounded authority bypass should be rejected regardless of score.

Keep separate:

hard constraints
portfolio leverage
reliability risk
engineering cost

Hard Dependency Constraints Come First

Examples:

must preserve tenant isolation
must preserve authorization boundaries
must preserve verifier independence
must preserve auditability
must preserve replay identity

Only after those pass should leverage economics matter.

Build the Graph From Real Evidence

Where do dependency edges come from?

Possible sources:

• architecture declarations,
• runtime traces,
• tool invocation logs,
• release manifests,
• verifier manifests,
• scheduler traces,
• provenance graphs.

Use both declared and observed dependencies.

Declared and Observed Dependencies Can Disagree

Suppose architecture documentation says:

capability X does not use retrieval

but runtime traces show retrieval calls.

That discrepancy is important.

It may indicate:

• hidden coupling,
• implementation drift,
• undocumented fallback behavior,
• policy violation.

Track it.

Dependency Drift Is a Real Failure Mode

Over time, capabilities acquire hidden dependencies.

new helper
new cache
new model call
new external API
new feature flag

If the graph is not updated, blast-radius analysis becomes wrong.

So dependency correctness needs monitoring.

Runtime Traces Can Validate the Graph

Compare expected dependencies against observed run dependencies.

expected dependency absent
unexpected dependency present
wrong version used
forbidden dependency used

These are architecture-drift signals.

Add Dependency Invariants

Examples:

production mutation must pass authority gateway
A4+ capability must use approved verifier class
forensic replay must not call live mutation tools
experimental skill store cannot be read by production agent

These are graph-level invariants.

Test them deterministically where possible.

Forbidden Edges Matter as Much as Required Edges

A dependency graph should also represent things that must not happen.

For example:

production_agent
    MUST NOT depend on
experimental_memory_store

or:

candidate_agent
    MUST NOT depend on
promotion_decision_service

Negative architecture constraints are extremely useful.

Example: Capability Acquisition Boundary

From Step 31:

experimental agent
    → sandbox tools
    → experimental memory
    → verifier

but NOT

experimental agent
    → production authority store

That forbidden edge should be testable.

Dependency Graphs Can Enforce Separation of Concerns

The graph can reveal whether your architecture has collapsed boundaries.

For example:

router
    calls verifier
    mutates memory
    changes authority
    edits policy

That component has probably become too powerful.

A graph makes this architectural smell obvious.

Centrality Can Reveal God Components

A node with massive inbound and outbound dependencies may be a legitimate platform core.

Or it may be a god object.

Investigate.

Ask:

is this centrality necessary?
are responsibilities coherent?
can failure be isolated?
can the component be tested independently?

Do not celebrate centrality automatically.

The Engineering Knowledge Graph Pattern

At this stage the dependency architecture starts to resemble a knowledge graph.

Nodes:

capabilities
primitives
policies
verifiers
models
tools
resources
releases

Edges:

DEPENDS_ON
VERIFIED_BY
AUTHORIZED_BY
RUNS_ON
USES
FALLS_BACK_TO
REPLACED_BY
INCOMPATIBLE_WITH

You do not need a graph database to benefit from the conceptual model.

But the graph abstraction becomes increasingly useful as the platform grows.

Query Examples

Useful queries include:

what capabilities depend on verifier X?

what capabilities lose A4 authority if browser pool Y degrades?

what primitives unlock the most currently unsupported demand?

which primitives have no fallback and high SLO exposure?

which competence claims depend on deprecated components?

which experimental capabilities require a primitive not yet production-ready?

These are architectural queries, not model prompts.

Dependency Graphs Improve Roadmap Sequencing

Suppose the roadmap wants:

Capability C1
Capability C2
Capability C3

And the graph says:

C1 → P1, P2
C2 → P1, P3
C3 → P1, P2, P3

Then the sequence may be:

P1
P2
C1
P3
C2
C3

rather than building each capability end to end independently.

But Do Not Build Every Primitive Up Front

Only build enough primitive capability to support validated demand.

This keeps the architecture evidence-driven.

Use Small Interfaces First

A new shared primitive should begin with the narrowest useful contract.

For example:

class SnapshotProvider:
    def capture(self, scope) -> Snapshot: ...

Do not begin with a universal repository/browser/database/world-state abstraction unless the evidence requires it.

Promote Primitives Like Capabilities

A shared primitive can begin experimental.

EXPERIMENTAL
    ↓
SHADOW
    ↓
LIMITED
    ↓
PRODUCTION

Its promotion should be based on downstream evidence.

This mirrors behavioral release engineering.

Primitive Competence Exists Too

A primitive may be reliable only in certain regimes.

For example:

browser state capture
    validated on Chromium desktop flows
    not validated on mobile web

That is a primitive competence envelope.

Do not let downstream capabilities silently extend it.

Capability Competence Is Compositional Only With Evidence

If:

primitive A works
primitive B works
primitive C works

it does not automatically follow that:

A + B + C capability works

Composition creates interaction effects.

End-to-end evidence remains necessary.

This Is Especially Important for Multi-Agent Systems

Suppose:

planner competent
executor competent
critic competent
verifier competent

The composed system may still fail because:

• information is lost between roles,
• the router misassigns tasks,
• the critic overrides correct work,
• concurrency creates stale state,
• the verifier observes a different artifact.

Joint competence must be measured.

Dependency Graphs Help Explain Joint Competence Failures

You can inspect:

which edge transferred the wrong state?
which dependency version differed?
which verifier path was skipped?
which fallback activated?

The graph becomes an incident-forensics aid.

Add Fallback Edges Explicitly

A capability might declare:

primary model → fallback model
primary retriever → lexical fallback
browser mutation → proposal-only fallback

These are part of operational behavior.

Record them.

Fallbacks Need Competence Evidence Too

A fallback is not safe merely because it exists.

If fallback behavior has not been validated for the task regime, it should not automatically inherit the primary capability’s authority.

This follows Step 22’s degradation rules.

The Graph Can Identify Unsafe Fallback Chains

Example:

primary verifier unavailable
    ↓
fallback verifier
    ↓
fallback model critic

If the final fallback is much weaker, the capability may need to reduce authority.

Graph-aware policy can enforce that.

Avoid Recursive Dependency Loops

Capability graphs can contain cycles.

Some cycles are legitimate.

For example:

monitoring depends on storage
storage monitoring depends on monitoring

But cycles deserve inspection.

In agent systems, dangerous cycles might include:

agent updates verifier
verifier approves agent update

or:

router chooses policy optimizer
policy optimizer changes router

These can collapse independence boundaries.

Detect Cycles Automatically

Run strongly connected component analysis.

Flag cycles involving:

authority
verification
promotion
policy mutation
security boundaries

Those deserve architectural review.

Not Every Cycle Is Wrong

A telemetry loop may be expected.

A self-authorizing loop is not.

Context matters.

The graph should surface cycles, not make the decision for you.

Add Ownership Metadata

Every critical primitive should have an owner.

owner team
on-call group
runbook
SLO
rollback procedure

A central dependency with no clear ownership is operational debt.

Ownership Should Follow Failure Responsibility

If a primitive can break eight capabilities, someone needs authority and responsibility to operate it.

Otherwise incidents bounce between feature teams.

The Graph Can Improve Incident Routing

If an incident affects capabilities A, B, and C and all depend on primitive P, route investigation toward P’s owner first.

This reduces duplicated debugging.

Capability Dependency Graph Metrics

Useful metrics include:

Portfolio leverage

How much validated demand depends on a primitive?

Critical authority concentration

How much high-authority execution depends on it?

Verifier concentration

How much acceptance evidence depends on it?

Fallback coverage

How much downstream capability has a validated alternative?

Dependency churn

How frequently does the primitive change?

Incident contribution

How much reliability-budget burn traces to it?

Change amplification

How many competence/release artifacts require revalidation after change?

Orphaned capability count

How many capabilities depend on deprecated or unsupported primitives?

Track Realized Platform Leverage

A primitive may have been justified because it was expected to unlock many capabilities.

Later, check whether it did.

predicted downstream capabilities
actual production capabilities
actual workload volume
actual reliability impact
actual maintenance cost

This calibrates architecture planning.

Platform Leverage Can Be Negative

A shared primitive might reduce code duplication but create so much operational fragility that its net value is negative.

That is possible.

Examples:

• universal router becomes a bottleneck,
• universal memory creates contamination risk,
• universal verifier creates correlated false PASS,
• universal retriever harms domain-specific relevance.

Do not assume centralization is good.

Sometimes Split the Primitive

If one component serves incompatible regimes, split it.

For example:

universal retrieval

might become:

repository retrieval
research retrieval
incident retrieval

while sharing only lower-level indexing infrastructure.

The graph helps identify the right boundary.

Sometimes Merge the Primitive

The opposite also happens.

Three capabilities may each implement their own identical:

artifact hashing
state versioning
idempotency

That is a good candidate for consolidation.

The graph shows duplication.

Consolidate Invariants Before Heuristics

A useful rule is:

shared deterministic invariant
    → strong consolidation candidate

shared fuzzy heuristic
    → inspect semantics carefully

This avoids universalizing domain-specific intelligence too early.

The Capability Graph Should Not Become a New God System

The graph exists to represent architecture.

It should not automatically own:

routing
scheduling
authority
release
verification

Those systems can query the graph.

Keep responsibilities separated.

Cache Graph Queries, Not Authority

It may be safe to cache:

downstream dependency list

It may be unsafe to cache:

this action is authorized

because authority can change with state.

Know which graph-derived outputs are stable.

Graph Staleness Is Itself a Risk

If dependency metadata is stale, decisions based on it may be wrong.

Therefore graph updates need provenance and validation.

Useful checks:

runtime dependency not declared
removed dependency still observed
version mismatch
graph release older than behavioral release

Use Runtime Evidence to Repair the Graph

The platform can propose graph corrections from observed traces.

But proposals should not auto-promote blindly.

This follows the same evidence-before-authority rule used throughout the series.

Graph Changes Should Be Reviewed Like Architecture Changes

A new edge can mean:

new coupling
new cost
new blast radius
new authority path
new revalidation obligation

That deserves review.

Example: Coding Agent Platform

Imagine these capabilities:

code explanation
bug localization
patch proposal
patch execution
refactoring
dependency upgrade
migration planning
incident repair

Shared primitives might include:

repository snapshot
symbol graph
search/retrieval
sandbox
patch engine
test runner
static analysis
verifier gateway
provenance
GitHub integration

The graph reveals which primitives unlock proposal capability versus production mutation authority.

Example: Research Agent Platform

Capabilities:

fact lookup
source comparison
literature synthesis
market research
policy analysis
watchlist monitoring

Shared primitives:

web retrieval
source identity
freshness
citation extraction
source authority scoring
snapshot retention
provenance
claim verifier

A citation verifier may be more valuable than another generation model because it raises the usable authority of several downstream capabilities.

Example: Browser Agent Platform

Capabilities:

page inspection
form filling
account updates
checkout assistance
workflow automation

Shared primitives:

browser session
DOM capture
credential isolation
mutation gateway
postcondition verifier
idempotency
approval service

The dependency graph should make read-only inspection much less dependent on mutation authority infrastructure.

That preserves graceful degradation.

Example: DevOps Agent Platform

Capabilities:

log diagnosis
configuration review
deployment proposal
deployment execution
rollback
incident recovery

Shared primitives:

telemetry retrieval
state snapshot
change planner
sandbox/staging
policy engine
approval
fencing
post-deploy verifier
rollback manager

The highest-value primitive may be the post-deploy verifier because it increases safe authority across multiple operations.

Example: Mixture-of-Agents Platform

Capabilities may depend on specialist agents.

coding specialist
research specialist
security specialist
critic
verifier

But shared dependencies may include:

router
context assembler
memory
model provider
scheduler
provenance

If all specialists share the same model family and same context bug, apparent diversity may be much weaker than it looks.

Graph the shared dependencies.

Measure Correlation, Not Just Topology

Two capabilities can share no explicit software dependency yet still fail together because they share:

• training/model family,
• prompt template family,
• data source,
• organizational process,
• reviewer group.

Topology is only one form of dependence.

Add Empirical Failure Correlation

From incident data, measure whether capability failures co-occur.

Then compare observed correlation with the structural graph.

Unexpected correlation may reveal hidden shared dependencies.

Hidden Dependency Discovery

For example:

capability A and B fail together

No declared shared dependency exists.

Investigation reveals both use:

same prompt compiler

That missing edge should enter the graph.

Dependency Graphs Improve Experimental Design

When testing a new primitive, select downstream capabilities that exercise different regimes.

For example:

retriever change
    test coding retrieval
    test research retrieval
    test incident retrieval

if all depend on the primitive.

This gives better coverage than testing one happy path.

Use Boundary Cases

For a shared primitive, test near its competence boundary.

Examples:

very large repositories
adversarial web pages
stale external state
partial telemetry
high concurrency

Shared primitives deserve broad boundary testing because errors amplify downstream.

Primitive Acquisition Can Use Step 31

A new shared primitive can itself be developed through sandboxed capability acquisition.

For example:

new semantic verifier

can be developed experimentally, calibrated, benchmarked, shadowed, then promoted.

The same scientific separation applies.

But Primitive Promotion Has Wider Consequences

Promoting a central primitive may implicitly affect many capabilities.

Therefore promotion evidence should include:

primitive-level tests
plus
downstream capability regression tests

This is dependency-aware release engineering.

Dependency-Aware Regression Suites

When a primitive changes, automatically select tests for its downstream capabilities.

changed primitive
    ↓
graph traversal
    ↓
impacted capability set
    ↓
regression suite

That is a very practical use of the graph.

Avoid Running the Entire World Every Time

The graph lets you select impacted tests rather than rerun every benchmark for every change.

This can reduce validation cost substantially.

But retain periodic full-system validation to catch hidden dependencies.

Dependency-Aware Canary Selection

A central primitive should canary across representative downstream cohorts.

Do not choose canaries only from one easy capability.

For example:

retriever v9 canary
    coding cohort
    research cohort
    incident cohort

This tests breadth of downstream effect.

Dependency-Aware Rollback

If a primitive rollback is required, ask:

which downstream releases remain compatible with the rollback version?

A primitive rollback may itself break newer capabilities.

This is why compatibility metadata matters.

Keep Known-Good Dependency Bundles

For important capability sets, store known-good combinations.

bundle_42:
    retriever 8.4
    verifier 3.2
    sandbox 5.1
    policy 12.0

This can simplify rollback during incidents.

Do Not Confuse Bundle Stability With Permanent Freezing

Known-good bundles are rollback anchors.

They are not an excuse to stop evolution.

Use controlled releases.

The Graph Helps Answer “What Should We Standardize?”

A shared primitive is a candidate for standardization when:

semantics are stable
dependencies recur
contracts are clear
failure modes are understood
operational ownership exists

Not merely because several teams wrote similar code.

The Graph Also Helps Answer “What Should Stay Local?”

Keep a mechanism local when:

domain semantics differ strongly
failure modes differ strongly
authority differs strongly
lifecycle differs strongly
shared abstraction would hide important variation

This prevents premature platformization.

Platform Teams Need Evidence Too

A platform primitive should prove that it reduces total system cost or improves reliability.

Measure:

downstream adoption
reduced duplicate implementation
reduced incidents
faster capability acquisition
better verified success
lower cost

Otherwise the platform may become overhead.

Platform Primitives Can Be Retired

If a shared primitive no longer earns its carrying cost, retire it.

For example:

universal critic service

might be removed if deterministic verifiers and specialist checks outperform it.

Shared does not mean permanent.

Retirement Requires Dependency Migration

Before retiring a primitive:

find dependents
identify replacements
validate compatibility
migrate capability by capability
verify outcomes
remove old edge

The graph provides the migration plan.

Capability Graphs and Technical Debt

Technical debt can be represented as dependency risk.

Examples:

unsupported primitive version
no fallback
unclear owner
weak verifier
high concentration
unknown compatibility

These are actionable debt signals.

Dependency Debt Is Often More Important Than Code Debt

A cleanly written shared component can still be dangerous if:

it is undocumented
unversioned
unowned
unverified
highly central

The graph exposes architectural debt that code quality tools may miss.

Add a Dependency Risk Review

For every high-centrality primitive, periodically ask:

what breaks if this fails?
how do we detect semantic degradation?
what fallback exists?
is fallback independently competent?
what is rollback time?
who owns it?
which competence claims depend on it?

This should be a recurring architectural review.

Capability Portfolio + Dependency Graph

Step 32 answered:

which capabilities should we own?

Step 33 answers:

which shared investments support them?

Together:

capability demand
      ↓
portfolio selection
      ↓
dependency graph
      ↓
shared primitive investment
      ↓
verified capability expansion

Reliability Economics + Dependency Graph

Step 28 asked where the next engineering hour should go.

The graph improves the answer.

A primitive fix may reduce reliability loss across several capabilities at once.

That can produce much higher expected return than a local patch.

Incident Forensics + Dependency Graph

Step 26 looked for the earliest causal divergence.

The graph helps identify plausible shared causes.

If five incidents across different capabilities share one primitive version, that is strong investigation evidence.

Not proof.

But strong evidence.

Drift Detection + Dependency Graph

Step 23 detected behavioral drift.

The graph lets you cluster drift by dependency.

multiple cohorts regress
all share verifier_v7

That is much more actionable than separate alerts.

Competence Envelopes + Dependency Graph

Step 30 defined competence relative to operating conditions.

Shared primitive versions are part of those conditions.

A capability is not simply competent on task class T.

It may be competent on:

T
with verifier V
retriever R
sandbox S
policy P

The graph formalizes those assumptions.

Capability Acquisition + Dependency Graph

Step 31 acquired capabilities experimentally.

Before launching acquisition, query the graph:

what missing primitive is blocking promotion?

Sometimes the best experiment is not teaching the agent a new skill.

It is building a shared verifier or state primitive.

The Architecture Principle

The dependency graph is not merely documentation.

It becomes a shared reasoning substrate for:

roadmap planning
release impact
incident forensics
scheduler admission
backpressure
competence validation
rollback
failure injection
portfolio economics

But keep one rule clear:

The graph informs decisions. It does not replace external evidence.

A Minimal Runtime

You can start with a tiny service.

from collections import defaultdict, deque


class CapabilityDependencyGraph:
    def __init__(self):
        self._deps = defaultdict(set)
        self._reverse = defaultdict(set)

    def add_dependency(self, capability_or_node: str, dependency: str) -> None:
        self._deps[capability_or_node].add(dependency)
        self._reverse[dependency].add(capability_or_node)

    def dependencies_of(self, node: str) -> set[str]:
        return set(self._deps[node])

    def direct_dependents_of(self, node: str) -> set[str]:
        return set(self._reverse[node])

    def affected_by(self, node: str) -> set[str]:
        affected = set()
        queue = deque([node])

        while queue:
            current = queue.popleft()
            for dependent in self._reverse[current]:
                if dependent not in affected:
                    affected.add(dependent)
                    queue.append(dependent)

        return affected

That already enables:

impact analysis
regression selection
blast-radius queries

You can add richer semantics later.

Then Add Policy Metadata

@dataclass(frozen=True)
class DependencyRequirement:
    dependency_id: str
    minimum_version: str | None
    authority_floor: str | None
    required_verifier_class: str | None
    fallback_id: str | None

Then the runtime can answer more meaningful questions.

Keep Graph Evaluation Deterministic

Graph traversal, version compatibility, required-edge validation, and forbidden-edge checks should generally be deterministic software.

Do not use an LLM to answer:

is dependency X required by capability Y?

when the architecture already declares the edge.

Use Models for Explanation, Not Authority

A model may summarize:

why primitive P is high risk

But the authoritative facts should come from:

graph
runtime evidence
SLO data
release metadata

This keeps reasoning inspectable.

Failure Mode: Feature-Count Leverage

A team prioritizes a primitive because it unlocks the largest number of capabilities.

But those capabilities are low-value and rarely used.

Fix:

weight by observed demand and capability importance

Failure Mode: Centrality Worship

A highly central component is assumed to be strategically valuable.

But it is actually a badly designed god service.

Fix:

review semantic cohesion and failure isolation

Failure Mode: Reuse Monoculture

One universal model/retriever/verifier becomes mandatory everywhere.

Fix:

domain-specific policy
independent fallbacks
failure-domain diversity

Failure Mode: Invisible External Dependency

The graph models internal services but ignores the external API every critical capability uses.

Fix:

include external systems and provider failure domains

Failure Mode: Missing Human Dependency

Production authority relies on one small reviewer group, but the architecture does not represent that bottleneck.

Fix:

model human review capacity as a dependency

Failure Mode: Shared Verifier Blindness

Several capabilities share one permissive verifier.

PASS rates remain healthy while quality collapses.

Fix:

central-verifier audits
independent gold cases
diverse mechanisms

Failure Mode: Stale Graph

Runtime behavior changes but architecture metadata does not.

Fix:

compare declared vs observed dependencies
alert on divergence

Failure Mode: Hidden Forbidden Edge

An experimental component gains access to production policy or authority state through a convenience integration.

Fix:

model and test forbidden edges

Failure Mode: Graph-Driven Overengineering

The team builds a universal graph platform before proving any operational need.

Fix:

start with explicit data structures and real queries

Failure Mode: Graph Replaces Verification

The scheduler sees all dependencies healthy and assumes success is likely enough to skip end-to-end verification.

Fix:

graph health never substitutes for outcome verification

Failure Mode: Unvalidated Fallback

A capability falls back to a weaker dependency and retains the same authority.

Fix:

fallback competence must be independently established

Failure Mode: Dependency Change Without Revalidation

A central retriever or verifier changes and downstream competence claims are treated as unchanged.

Fix:

dependency-aware release impact and revalidation

Failure Mode: False Redundancy

Two backup services share the same provider, region, quota, or model family.

Fix:

model failure-domain metadata

Failure Mode: Universal Queue

All capabilities share one queue and one saturated dependency stalls unrelated work.

Fix:

bulkheads and resource-aware scheduling

Failure Mode: Capability Teams Own Shared Risk Separately

Each feature team manages the same central primitive independently.

Fix:

explicit platform ownership and SLOs

What Should You Measure First?

Do not begin with fifty graph metrics.

Start with:

1. downstream production capability count
2. critical-authority dependent count
3. fallback availability
4. verifier role
5. recent incident association
6. dependency churn
7. declared-vs-observed mismatch

That already exposes a lot.

A Useful Review Table

The exact numbers are less important than making the architecture discussable.

The Goal Is Not Maximum Reuse

The goal is not:

one primitive for everything

The goal is:

coherent shared primitives
with explicit contracts
bounded failure domains
validated fallbacks
and measurable portfolio leverage

That is a much stronger architecture.

The Goal Is Not Maximum Independence Either

Duplicating every subsystem per capability creates:

higher maintenance
inconsistent safety rules
inconsistent provenance
inconsistent verification
slower capability acquisition

The correct design balances reuse against correlation risk.

A Practical Decision Procedure

When considering a new primitive or consolidation, ask:

1. Which real capabilities need it?
2. Are their semantics actually shared?
3. What verified value does it unlock?
4. What authority paths depend on it?
5. What happens if it fails semantically, not just operationally?
6. What fallback exists?
7. Is that fallback independently competent?
8. Does consolidation create dangerous correlated failure?
9. Can we isolate resources or authority while sharing implementation?
10. How will dependency changes trigger revalidation?

If those answers are weak, do not centralize yet.

The Series So Far

At this point, the advanced-agent architecture has grown from search techniques into a full production engineering discipline.

reasoning techniques
      ↓
verification
      ↓
observability
      ↓
adaptation
      ↓
budget scheduling
      ↓
uncertainty decomposition
      ↓
value of information
      ↓
speculative concurrency
      ↓
distributed coordination
      ↓
platform scheduling
      ↓
failure containment
      ↓
drift detection
      ↓
release engineering
      ↓
replay/provenance
      ↓
incident forensics
      ↓
SLOs/error budgets
      ↓
reliability prioritization
      ↓
authority boundaries
      ↓
competence envelopes
      ↓
sandboxed capability acquisition
      ↓
capability portfolio
      ↓
capability dependency graph

The architecture is increasingly less about making an LLM clever.

It is about building a system that knows:

what it can do
what it should do
what it may do
what evidence supports those claims
what shared mechanisms those claims depend on

The Principle to Keep

The capability dependency graph gives you two views at once.

It shows leverage:

one primitive
    ↓
many capabilities

And it shows concentration risk:

one primitive fails
    ↓
many capabilities degrade

You need both.

So the rule is:

Invest in shared primitives when they unlock verified portfolio value, but treat high-centrality dependencies as explicit reliability and governance boundaries.

That is how you get the benefits of a platform without accidentally creating a monoculture.

What Comes Next

Once the capability graph exists, another problem becomes visible.

The platform may know:

which capabilities depend on which primitives

but it still needs to decide:

where should a capability run?
which model/provider/region/tool instance should serve it?
how should the platform place work across heterogeneous resources?

A local model may be cheaper.

A frontier model may be stronger.

A particular verifier may only exist in one environment.

A GPU may be saturated.

A browser provider may be degraded.

A tenant may require data residency.

A task may require specific tooling or authority boundaries.

The next stage is capability-aware placement and heterogeneous execution.

Not merely:

route task to model

but:

task requirements
      ↓
competence envelope
      ↓
dependency availability
      ↓
resource / cost / latency / residency constraints
      ↓
placement decision
      ↓
verified execution

That is where a real agent platform starts to behave like an operating system for heterogeneous intelligence.