# Advanced Agents From First Principles 33: Which Shared Components Actually Unlock More Capability? Build a Capability Dependency Graph
# Book: Advanced Agents From First Principles
# Chapter URL: https://programmer.ie/books/advanced-agents-from-first-principles/33-chapter/
# Prose fingerprint (sha256, normalized): 37f59e5566c93f67854dd6267106f12592e4e186c700e82c2d631e85cd1c03f1
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

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 Primitive Unlocks Critical Dependents Fallback Failure Domain Main Risk repository snapshot 7 4 partial internal storage stale state verifier gateway 9 6 weak shared service correlated false PASS sandbox runtime 6 3 none compute cluster capability outage provenance store 8 2 degraded logs database forensic blindness browser provider 4 2 secondary provider external workflow outage 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.