How Superintelligence Works | Agent Dependency Maps

An agent dependency map shows which services, data stores, models, permissions and human decisions a user task actually needs to reach a verified result. It helps engineers answer a practical question before an outage: if this component fails, which user intentions must stop, which can continue through an authorised alternative, and which external effects might already have happened? A useful map is directed and specific to the task, not merely a drawing of every API the organisation owns. It distinguishes a missing tool response from a failed external action and never invents a successful outcome because a fallback produced plausible text.

To build one, list the accepted task contracts, follow their actual read and write paths, classify each dependency as required or optional, identify shared infrastructure that may fail together, and test the proposed isolation route with controlled faults. This chapter models a fictional learning-service workload of one hundred intentions, counts the blast radius of failures in a library lookup, booking system, billing ledger and notification service, and calculates a bounded cache fallback. It also explains why multiplying component availabilities can mislead when outages are correlated. These are engineering controls for present-day AI-assisted workflows, not proof that artificial superintelligence already exists.

Start at the How Super Intelligence Works hub for the wider machine-intelligence system. The observability chapter follows the traces of what happened, while this chapter maps expected dependencies and their user-visible failure reach. Backpressure and circuit breakers cover one class of protective mechanisms; disaster recovery covers restoring a failed service. Dependency mapping comes earlier: understanding which capability depends on what, with which alternatives and consequences.

Choose a reading route

Building an assistant with several tools? Read the graph, edge types and one-hundred-intent packet.
Operating a production system? Focus on shared failure domains, fault isolation and independent readback.
Learning reliability engineering? Recalculate the blast radius and the illustrative availability products.
Teaching systems thinking? Use the transfer exercise to show why dependencies and consequences differ.

1. Map dependencies for the user task
2. Build a directed dependency graph
3. Hard, soft and shared dependencies
4. Failure domains and correlated risk
5. Worked laboratory: one hundred intentions
6. Calculate blast radius by affected intents
7. Isolate a failure without guessing success
8. Availability arithmetic and its assumptions
9. Verify actual edges with traces and receipts
10. Diagnose and repair common failures
11. Changed-context transfer and solved answer
12. Limits, user duties and organisational choices
Frequently asked questions
Primary technical sources
Further reading paths

1. Map dependencies for the user task

A component list is not enough. The statement “we use a model, database, calendar, web search and messaging service” does not tell you which tasks require each component. A lesson-planning suggestion may need a current source but no external write. A rescheduling request may require identity verification, an explicit approval, a booking update and confirmation. A billing correction may depend on a separate accounting service and human finance authority. Treat each accepted task as a path through capabilities, not as a single monolithic “agent is up” status.

Begin from the user’s outcome and work backwards. For “tell me the next available class,” identify authoritative schedule data and its freshness requirements. For “change my Tuesday booking,” identify identity, appointment reference, permission, current availability, side-effecting booking API and independent readback. A model can help formulate questions but cannot replace the source-system observation or turn a guessed schedule into a confirmed reservation. Each edge of the map should have an acceptance criterion.

Name the source of truth for consequential effects. A tool invocation that returns a queue receipt may mean “accepted for processing,” not “the database now shows the requested state.” Record which system determines final truth and how that determination can be retrieved after a timeout. Mark irreversible or externally visible actions clearly. A failure map that stops at HTTP success can obscure partial effects and lead operators to retry in ways that duplicate bookings or invoices.

Also specify time sensitivity. A cached timetable may be adequate for discussing typical lesson durations but inappropriate for promising that a particular seat is available now. A past scientific reference may remain useful after a retrieval outage, while a balance or account permission must be checked against the authoritative current system. The same dependency can be hard for one task and soft for another. Classify the task, source freshness and consequence rather than granting a cache universal authority.

2. Build a directed dependency graph

Represent each task path as a directed graph. Nodes are components or authorisation checkpoints, while edges are specific dependencies: must read, must write, must verify, may use as fallback, or must obtain permission. The direction matters. A model might require a library result to answer a factual question, but the library does not require that model to store books. A notification service may depend on a completed booking event, while the completed booking should not be undone simply because an email cannot be delivered.

Use stable identifiers and types. “Database” is too vague when one service owns booking state and another only holds a search index. “Human approval” is too vague when different reviewers may authorise different operations. Record environment, region, owner, data classification, key permission, expected latency, failure semantics and independent verifier for each significant edge. A map should let an on-call colleague find the owner and test plan without interpreting a pretty diagram as an execution log.

The graph should contain negative relationships as well. A reading-only library lookup must not depend on or receive a billing credential. A fallback summariser should not gain a broader data store just because the primary service is unavailable. An identity service might be a common prerequisite for all personalised tasks, but a public, non-sensitive educational explanation may not need account access. These boundaries create opportunities for safe isolation when one region, issuer or provider is unhealthy.

A graph changes as the application changes. New tools, new model routes, data migrations, human-review rules and time-limited permissions add or remove edges. Include the graph version in change reviews and confirm it against actual traffic rather than expecting a static architecture picture to remain true forever. Configuration alone may miss undocumented retries, monitoring exporters or direct network calls. A trustworthy map has both a designed view and evidence from observed execution.

3. Hard, soft and shared dependencies

A hard dependency is necessary for a particular accepted outcome. If booking changes must be written to a specific system of record, the booking service is a hard dependency for that action. A soft dependency improves speed or experience but may be bypassed under an approved degraded mode. A search index might be soft for a source that can be read directly, subject to freshness and access rules. An optional recommendation engine may be skipped when it fails. These labels belong to task paths, not to services in the abstract.

Fallback requires an explicit contract. A backup source should have comparable authority, supported data semantics, allowed identity and a testable acceptance rule. If a primary tool times out after a write, an alternative should not blindly repeat the action. Reconcile the destination using a stable intention and operation reference first. If the provider cannot show whether the write occurred, mark the result uncertain and route the exception through a safe human process rather than tell the user everything is complete.

Shared dependencies create a different kind of risk. Several nominally independent tools may use the same identity provider, network path, cloud region, database cluster or DNS service. Adding a second API endpoint under the same outage domain may not improve reliability at all. Your diagram should expose common roots and correlated failure modes, not count vendor names as independent sources of resilience. The engineering goal is to know which failures can cross between user tasks.

Separate failure of access from failure of evidence. A cached result might be available after the live library service fails, but the cached document could still be too old for a current availability claim. Conversely, a live service might return a well-formed answer that lacks the evidence needed for the user’s question. A fallback should preserve source identifiers, time semantics, scope and a policy for declining unsupported promises. Technical uptime is a narrower property than a trustworthy completed task.

4. Failure domains and correlated risk

A failure domain is a set of components likely to be affected by one underlying event. Examples include a region outage, a misconfigured shared credential, an overloaded common queue or a broken schema introduced across all connectors. A dependency map should explicitly identify these domains, so engineers do not treat two replicas in the same damaged environment as independent rescue systems. A recovery plan that assumes independence without testing it may fail exactly when many users need it.

Google’s Site Reliability Engineering chapter Addressing Cascading Failures explains how overload in one part of a service can increase pressure on the remaining parts and propagate failure. The chapter describes strategies such as overload protection and controlled retry behaviour. It supports the general dependency mechanism but does not define a single AI-agent architecture. Agent toolchains inherit distributed-systems failure patterns; the language model itself does not cancel network queues or prove that a retry is safe.

Annotate a graph with the possible amplification route. If the library search fails, do agents immediately call a broader, slower model for every request? Does that fallback query the same failing network? Will clients retry each call several times? Can the slower alternative block booking work sharing the same worker pool? A failure that began in an informational branch may then spread to independent write operations because of shared resource pressure. The map reveals where to apply admission limits and isolation.

An incident can also have a nontechnical common cause. If one incorrect policy update reaches every approval service, apparently independent regions may make the same authorisation mistake. If source material is corrupted upstream, several retrieval models may produce matching but unsupported answers. Treat correlated policy, data and human decisions as possible failure domains alongside hardware and network. A resilience claim should name what is truly independent and what is merely replicated.

5. Worked laboratory: one hundred intentions

The fictional Willow Learning Portal receives one hundred distinct user intentions during a teaching day. All are from authorised accounts, so each request first relies on a common identity service I, and each uses an application model route M. Forty intentions ask for current study-resource information that normally requires the library source L. Thirty-five request changes to existing tutoring bookings through booking service B. Twenty-five request a billing correction through accounting service G. The sixty change requests require the notification service N for a fully communicated outcome. The counts and system arrangement are invented for teaching, not a measured workload or a statement about any real tutoring provider.

Draw the paths. Information: I → M → L → verified response. Booking: I → M → valid human or policy approval → B → independent booking readback → N. Billing: I → M → authorised finance review → G → authoritative ledger readback → N. The approval steps are not machines the model may bypass. The graph can be elaborated with logs, queues and database replicas, but this small model is enough to calculate which user intentions depend on a selected component. The task path includes its accepted final outcome, not merely whether an API endpoint responds.

The first drill disables L for a bounded period. Forty information requests lose their normal live source, while the sixty booking and billing intentions do not require the library service under the stated contract. That is the initial dependency-based blast radius: forty of one hundred distinct intentions, or 40%. If the library failure saturates a shared worker pool and delays the other sixty tasks, the observed blast radius would be larger. The graph therefore specifies an intended isolation boundary that must be tested, not a promise that cross-effects cannot occur.

Of the forty information intentions, operators have an authorised cached catalogue snapshot for eighteen queries whose acceptance contracts permit the known age and scope of that snapshot. The other twenty-two require live availability or new material and cannot be answered reliably from that cache. The tool runner serves the eighteen with clear source-date context and verifies that no prohibited personal data is exposed. The twenty-two are held with accurate status. Neither a model-generated guess nor a cached answer with missing freshness metadata is counted as a successful response.

Under this simulated single fault, the sixty action intentions complete through their unaffected paths, and eighteen information requests complete through the approved cached route. Total verified useful outcomes are 60 + 18 = 78. Held intentions number twenty-two. The post-isolation unfulfilled fraction is 22 ÷ 100 = 22%, not the original 40% raw dependency reach. The fallback preserved eighteen useful outcomes, or 18 ÷ 40 = 45% of the at-risk information requests. Each statistic answers a different question: initial exposure, fallback success among affected tasks or incomplete user outcomes across the workload.

40 information intents depend on library L; 35 bookings depend on B; 25 billing changes depend on G.
Common identity I and model route M each participate in all 100 synthetic personalised task paths.
Notification N is needed for completed communication on the 35 + 25 = 60 change requests.
Library L single-fault exposure: 40 intents; approved cache can satisfy 18, leaving 22 held.
After the L outage under tested isolation: 60 unaffected completed + 18 approved fallbacks = 78 confirmed useful outcomes, 22 held.

Now imagine the notification service N is unavailable instead. Sixty action requests have a delivery dependency. A booking or billing update may already have been accepted and verified in its system of record, so the operator must not retry the original write to repair the missing notification. Record the completed state change and a pending communication step separately, with a bounded, idempotent delivery process. If the accepted user contract includes a delivered receipt, the full outcome is not yet complete until delivery is confirmed. The graph exposes why one failed component can leave partial but real effects elsewhere.

Consider a common identity-provider failure. In this teaching packet, I is required for all one hundred personalised tasks, so its immediate logical blast radius is the full workload. A public, nonpersonalised educational explanation might bypass identity under a different policy, but none of our hundred tasks has that contract. Avoid inventing a general-purpose bypass when the protected source requires authentication. The safer degraded mode may be to offer generic public reading while refusing to access or change personal records.

6. Calculate blast radius by affected intents

For a dependency node X, define reach in this packet as the number of distinct accepted intentions whose required path includes X, divided by one hundred. Thus reach(L) = 40%; reach(B) = 35%; reach(G) = 25%; reach(N) = 60%; and reach(I) = reach(M) = 100%. The numerator counts intentions, not the number of API calls or internal retries. One booking intent that makes three read attempts is still one user intention. Otherwise a failing system can appear to have a larger user population simply because it retries more often.

Do not add reach percentages mechanically. Notification N reaches sixty tasks, booking B thirty-five and billing G twenty-five, but B and G are disjoint categories in this experiment and their sixty actions all also reach N. Adding 60% + 35% + 25% would imply 120% affected intentions, which is impossible for a union of one hundred distinct cases. Use set relationships. The union of B and G users is 35 + 25 = 60, while the union of N and B or G is also sixty, not one hundred and twenty.

A blast-radius heat map should distinguish planned path dependency from observed failure. The graph may show that L is required by forty intentions, but the cache fallback narrows the unfulfilled set to twenty-two after testing. Another event may make L merely slow and trigger cascading requests against M. The observed outcome then depends on queue admission, shared resources, timeouts and whether people receive completed results. A good report preserves the raw graph exposure and the readback-confirmed business effect separately.

The same method helps avoid inflated financial claims. An engineer should not say “one component failure cost us 40% of revenue” because forty of one hundred intents had a dependency on it. Some were informational, some were recoverable, some carried no purchase intention and none was assigned a documented monetary value. The meaningful metric here is task reach and verified fulfilment. A financial estimate would require separately grounded consequences, units, attribution and data rather than a repackaged availability percentage.

7. Isolate a failure without guessing success

Isolation starts by identifying which task classes can safely run without the faulty component. If L becomes unavailable, route only the explicitly eligible information reads to the cached catalogue, with a source age and an accepted freshness rule. Do not send booking writes through that cache. If the booking system B is down, let independent information requests continue and mark booking updates queued or held according to current permission and deadlines. The application should have separate concurrency and retry budgets so one unhealthy branch cannot monopolise capacity for the rest.

Design fallback selection as a contract, not an optimistic model instruction. For every alternative, identify source authority, data class, supported operations, permission, freshness requirement, failure response and independent verification. Test its output under deliberately changed data. If the alternative gives an answer without citing a relevant current source, or proposes an operation it cannot actually execute, return a bounded partial answer or decline. Protect a human’s ability to see that the normal service is degraded.

If a tool timeout leaves an external write uncertain, first inspect the original system of record using the stable intent ID, operation reference or provider reconciliation key. A timeout can occur after the service committed the change. Repeating the write without investigation can duplicate or conflict with a legitimate action. The task might proceed through a different communication channel only after the real transaction state has been confirmed and the new channel is authorised. Isolation must preserve correctness, not merely uptime.

Circuit breakers, load shedding and backoff can help contain cascading load, but their configuration depends on actual failure and recovery behaviour. A breaker that opens too eagerly might deny legitimate work; one that never opens allows retries to amplify stress. Refer to the existing agent backpressure guide for those mechanisms. The dependency map supplies a prior question: which routes should be protected from a fault, and which tasks should be allowed into a degraded mode?

Recovery requires more than waiting for a green endpoint. After L returns, test source version, response quality, permission and retrieval freshness. Reconcile held requests against the current user mandate; some may have expired or been superseded. Do not replay obsolete instructions simply because the service recovered. A user-facing report should state which work completed during the outage, which remained pending and which was deliberately not executed. Evidence of restored health and evidence of finished user intentions are different records.

8. Availability arithmetic and its assumptions

Dependency maps can support a toy availability model, but only with explicit assumptions. Suppose that over a chosen period the identity service is available 99% of the time, the model route 99.5%, and the library source 97%. If their failures were independent and the information task required all three, simple multiplication would give 0.99 × 0.995 × 0.97 = 0.9554985, or approximately 95.55% path availability. The values are entirely invented and the independence assumption is strong; the computed percentage is not an observed service-level objective.

For a separate fictional booking path, assume the same 99% identity and 99.5% model availability, a 98% booking-system availability and 96% notification availability. Under the same independent-series simplification, the probability that all four components are available is 0.99 × 0.995 × 0.98 × 0.96 = 0.92673504, or approximately 92.67%. This number describes simultaneous component availability under our assumptions, not the probability that an authorised booking operation will be correct, accepted and independently verified.

Real components are often not independent. The same cloud outage, shared credentials, software deployment or network path can take out identity, model routing and notification together. In such cases multiplying their average availability can misstate the path’s actual reliability. Even independent component successes may have mismatched definitions: an endpoint may respond but return stale data, or the model may generate plausible text without completing a tool action. Define service-level indicators at the user-visible task boundary and compare them with actual observed outcomes.

A parallel fallback introduces still more conditions. The formula for either of two independent routes working differs from the product for both routes working, but applies only if both alternatives truly satisfy the same acceptance contract and have known dependence. If a cache cannot answer current booking availability, it is not a redundant booking route at all. Draw what the user actually needs before doing attractive probability algebra. A correct formula attached to the wrong task contract is a misleading calculation.

9. Verify actual edges with traces and receipts

Distributed tracing helps discover how logical requests travel through components. The OpenTelemetry documentation on traces explains spans and parent-child relationships for operations. Current OpenTelemetry generative-AI conventions also describe agent and tool spans, with some areas in development; do not assume that every implementation records identical fields or reliably captures tool results by default. Traces are evidence of observed calls and timing, not guarantees that an external business state changed.

Correlate a trace to a stable user intent while minimising sensitive content. Useful dimensions include task class, approved model route, tool type, provider, source version, failure classification, time and independently verified outcome. Avoid logging private prompts, student information or credentials merely to decorate a diagram. The map can be generated in part from observed spans, but should also include documented dependencies that are rare, optional or absent from a narrow observation period.

A useful consistency check compares designed edges with observed traces. If the team says information requests never use billing service G, but a trace reveals a billing call during a library outage, the unexpected edge deserves investigation. It might be a shared audit sink, a misconfigured fallback or a new feature that was not included in the change review. Do not conceal it because the response ultimately succeeded. Unexpected dependencies can turn local failures into larger incidents.

Not every relevant edge is observable through automatic instrumentation. A human approval, provider contract, legal retention obligation or offline manual export may be essential to a completed task without appearing as a conventional network span. Combine system telemetry with process contracts and evidence of real approvals and source-system outcomes. The map must represent the user-facing system as actually operated, rather than pretending the observable software trace is the whole world.

10. Diagnose and repair common failures

Failure A: a library outage blocks booking changes that do not need library information. Diagnose shared worker pools, synchronous dependencies, oversized retries or an incorrectly unified workflow. Isolate task queues and budgets, remove unnecessary hard edges and test with the library deliberately unavailable. Verify that booking outcomes complete correctly, not merely that the booking API receives requests. Do not weaken identity or approval checks to make a graph look more robust.

Failure B: two tools are called independent because they have different URLs, but both use the same identity issuer. Diagnose an unrecorded common failure domain. Add issuer and region dependencies to both paths, test appropriate simulated failures and document realistic residual risk. A second endpoint may improve provider-specific failure coverage while doing little against a shared issuer outage. Avoid marketing redundancy on the basis of interface count alone.

Failure C: a cached library summary is presented as a current seat-availability guarantee. The fallback violated its evidence freshness contract. Separate general explanatory queries from live mutable-state checks, give cached results visible dates and refuse unsupported transactional claims. Retest with a booking slot that changed after the cache snapshot. The model should explain the limitation rather than invent a new confirmation.

Failure D: the notification service fails after a booking update, and an operator repeats the booking change. The missing edge was not booking availability; it was downstream communication. Preserve the authoritative booking receipt, reconcile the committed state and retry only the idempotent notification path under current authorisation. A communication failure must not generate a second appointment or a contradictory finance entry.

Failure E: a dependency chart reports that the service is fully restored while users still have held and expired requests. Diagnose a monitoring definition that counts healthy components but not completed intentions. Reconcile the backlog by ID, check permission expiry and external effects, then close each request as confirmed, rejected, expired or unresolved with truthful explanations. Restoring technical endpoints is necessary but not always sufficient for service recovery.

Failure F: the map’s statistics improve because the team counts repeated attempts as additional completed requests. Restore stable intention identity, distinguish attempt counts from unique task counts and independently verify source-system receipts. One user instruction with five retries is not five customers helped. Publish denominators with every metric and test how the dashboard reacts when one unreliable connector produces many automatic retries.

11. Changed-context transfer and solved answer

Transfer the graph method to a fictional community-library portal with fifty daily intentions. Twenty are general public catalogue questions that use source C and require no personal identity. Twenty are booking modifications that require identity I, booking service B and notification N. Ten concern account adjustments requiring I, ledger G and N. The task paths are separate under the fictional rules. If identity I becomes unavailable but all other services work, how many intentions are directly affected, and which might continue without inventing a bypass?

Worked solution: the twenty booking modifications and ten account adjustments require I, so thirty of fifty are affected, equal to 30 ÷ 50 = 60%. The twenty genuinely public catalogue questions can continue through C without personal identity. They are not an authorised route for viewing or changing private booking records. The result differs from the earlier hundred-intention packet, where every request was personalised and identity was a shared hard dependency. The graph must reflect the actual task and authority boundary.

Now suppose C also fails. Of the twenty public questions, eight can be answered from a permitted, date-labeled snapshot and twelve require fresh source information. With identity I and C both unavailable but B, G and N healthy, the portal can complete eight public questions through the approved snapshot, while thirty private requests are held because identity cannot be verified and twelve public requests are held for source freshness. Total confirmed useful outcomes are eight; held intentions are forty-two. The overlap was not double-counted, because the catalogue and personalised populations were disjoint in this exercise.

Change one more condition: the public catalogue service begins to return personalised borrowing history when a user identifier is supplied. Does this make C an authorised fallback for failed identity I? No. A new private-data capability introduces an identity and permission boundary for those specific requests. A request that requires personal account verification cannot become a public query just because the same endpoint also supports anonymous reading. Revise the graph, source contract and access tests before accepting any alternative path.

For independent practice, draw two graphs for a school event registration service: one for viewing a publicly announced schedule and one for cancelling an individual’s reserved place. Mark every live source, permission check, possible write and confirmation. Disable one component in your drawing and predict which outcomes remain permissible. Then ask what evidence would disprove your prediction. The exercise is complete only when the user-visible result, not just component status, is described.

12. Limits, user duties and organisational choices

A dependency map is a model of selected relationships, not the system itself. It may omit rare paths, undocumented scripts, new third-party behaviour, human workarounds or adversarial data flows. A graph can show what is necessary under known contracts but cannot guarantee that a provider is truthful, an AI model will produce a correct answer or a reviewer will make a good judgment. Combine architecture review with controlled faults, observed traces, source verification and post-incident investigation.

Failure isolation also has trade-offs. Stronger separation can cost more infrastructure and coordination. Aggressive fallback can increase inconsistency or extend permissions. A policy that holds sensitive work during uncertainty may look slower but protects people from duplicate or unauthorised effects. Choose degraded modes based on consequence and reversibility rather than an unqualified desire for uptime. User trust depends on accurate descriptions of what completed, what is pending and what never ran.

Organisations need named owners for the map, each significant dependency and the conditions for revising it. A new integration or policy change should be reviewed for new shared failure domains and changed authority. A model may help summarise traces or draft a risk register, but the final decision to accept risk and authorize external action belongs to the appropriate people and controls. Nothing in the map implies presently existing artificial superintelligence; it is disciplined engineering for current AI-assisted systems.

Frequently asked questions

Is a dependency map just a drawing of microservices?

No. It connects user task contracts to required sources, tools, permissions, side effects and verification, including human steps and important non-network dependencies. A microservice diagram may be one input.

What does blast radius measure?

In this chapter it measures distinct user intentions whose required paths include a failed component, with a separate count of tasks still unfulfilled after approved fallbacks. A retry count or total traffic volume is not the same denominator.

Can cached information substitute for any failed API?

Only when the cached source, date, data class, permission and accuracy limits satisfy the particular user task. A snapshot of a timetable cannot automatically prove a live seat is still available.

Why must a timed-out write be reconciled before retrying?

The external system might have committed the action before the response was lost. A second write could duplicate or conflict with it. Look up the original operation and confirmed state first.

Do complete traces prove every task completed?

No. Traces show observed operations and timing, subject to instrumentation limits. Independent source-system receipts and validated user outcomes are needed for consequential work.

When can component availabilities be multiplied?

Only under a clearly specified series-system model with appropriate independence and matching definitions of success. Shared failures and user-visible acceptance requirements can invalidate a naive product.

Primary technical sources

Google SRE Book, Addressing Cascading Failures: propagation, overload and reliability mechanisms.
OpenTelemetry, Traces: tracing concepts for following operations through distributed systems.
OpenTelemetry generative-AI agent conventions (development): evolving agent and tool span descriptions.
NIST AI RMF 1.0: broader governance and measured AI risk, not an agent reliability certification.

How Superintelligence Works | Agent Dependency Maps — Failure Domains, Blast Radius and Safe Isolation