Dependency Graphs: What Can Run in Parallel

A dependency graph shows which result is needed before another piece of work can start or finish. It helps you tell a genuine wait apart from a merely preferred order, find places where parallel work is safe, and see what could delay the whole result. It is a model of sequence, not an exact description of the whole project: on its own it cannot see people's availability, the difficulty of integration, unexpected decisions or the uncertainty in estimates.

The examples below use a fictional booking service. The times, numbers of days, participants and results are invented for teaching and are not data about a real project.

After this unit you will be able to:

• read the direction of a dependency between two tasks correctly;
• separate a logical prerequisite, a decision, a permission and a resource constraint;
• find the critical path, calculate the slack for non-critical work and test an alternative order;
• explain why work that can start in parallel may still need sequential review or a joint integration;
• spot a cycle and extract the shared decision or contract hidden inside it;
• update the plan after new information without leaving a hidden dependency buried in a message thread;
• hand parts of the work to agents with named prerequisites, resources, an integration owner and evidence of completion.

Node, edge and direction

A node is a piece of work or a result with a clear boundary. For example, "agree the response of the cancellation route" is better than "work on the server", because the result tells you exactly what the next part will be waiting for.

An edge is a dependency between results. In this unit an arrow points from the required prerequisite to the work that uses it:

A → B means: work B needs the result of A.

If an API (application programming interface) route needs an approved response schema, we have "agree the contract → implement the route". The direction says nothing about which work is more important or how long it takes.

Prerequisite	Next piece of work	What exactly it waits for
The decision-owner has confirmed the cancellation terms	The team implements the rule	Permitted statuses, the time limit, the consequence for the user
The route's response format has been agreed	Server and client implement their parts	The field name, the possible states and the shape of a refusal
Access to the test calendar has been granted	The integration check	Permission to make a real request in the test environment
A compatible migration has been verified	Safe deployment of the schema	The transition plan, the old version's behaviour and the recovery path

In everyday speech, "A blocks B" means B cannot reach the named finished state without A. It is more useful, though, to phrase a dependency positively: "B uses X, which A produces." That shows exactly what is missing. The words "it depends on something else" do not say whether a result, a decision, a permission, a shared resource or merely a conversation is needed.

A prerequisite is a result needed to start or accept a piece of work. A dependency is the name for a link between parts. A blocker is an obstacle currently holding one of them up. These ideas are related but not identical. For example, access to the provider's calendar is a dependency of the integration check against it, and it remains that check's blocker until access is granted. The booking-view route may not depend on that check at all, and can move ahead without it, if rescheduling has been postponed.

In the plan, record each node with its expected evidence, and for each edge record the producer, the consumer, the result needed and the condition for readiness. An edge without an explanation easily turns into an open-ended "we're waiting for another department" that nobody can resolve.

In a task tracker, a "blocks" or "is blocked by" link sets a direction, but on its own it does not describe a contract or partial readiness. The Jira Cloud documentation for timeline dependencies, for example, treats them as an ordering in which one piece of work must finish before the next begins. If people can in fact start earlier, describe the difference between starting, finishing, checking and releasing in the task itself — what waits for integration, for a check or for release — rather than relying on an arrow in the tracker alone.

Direction is not a calendar

A link between A and B does not always forbid starting B before A is finished. It may turn out that A's shared result is needed only for the final check, while a developer can already prepare part of B against an agreed temporary arrangement. At other times even starting would be wasted effort: if the owner is still deciding whether cancellation is allowed at all, it is too early to write the final server rule.

Find out which output of A is needed, at which stage — to start, for review, for checking or for release — and who will provide it and confirm it is ready. A provisional contract or a stub may let work begin earlier, but it does not replace the later check against the real provider.

"Can start" is not the same as "can finish, merge, deploy or hand to users". Plan at least these boundaries separately. If the team writes a screen and a route in parallel against an agreed response schema, their coding may not block each other at all. The integration check, however, still needs both changes and the real contract.

Do not mark a preferred order as a hard edge without a reason. "Do all the server tasks first, then move on to the interface" is not a dependency unless specific data, decisions or shared files require it. Such an artificial order reduces parallelism and hides what actually needs agreeing.

For every link, ask:

• Which specific output of A does B need?
• Is a provisional contract or a test scenario enough to start part of B?
• At which step does the dependency become mandatory: the first line of code, review, checking or release?
• Who can supply the missing decision or access?
• What observation will confirm that the prerequisite has been met?
• Can B be checked against a stub first, and then — without fail — against the real provider?

A directed graph without cycles

When every arrow points from a prerequisite to its consumer, the network is called a DAG (directed acyclic graph). "Directed" means each edge has a direction; "acyclic" means that if you follow the arrows you can never come back to the same node.

This is useful for planning: if the graph has no cycles, there is at least one order in which every prerequisite finishes before the successors that need it. When there is a cycle, it is impossible to satisfy every hard dependency while keeping all the boundaries as they are. The model needs refining: is there a shared prerequisite nobody named? Are both parts really needed before the first check? Does the dependency actually concern finishing rather than starting? Or should the contract be redesigned?

A cycle in the diagram does not prove the product cannot be built. It shows that the current description of the requirements or the order of work does not yield a consistent plan. Iterative work may alternate discovery and implementation, but the plan must still name the first checkable agreement from which the cycle can be entered.

If the diagram has hard arrows A → B and B → A, don't fix it by endlessly reassigning statuses. Check where each arrow comes from. For example, the client form may be waiting for the API's error, while the API developer waits for the final wording of the form. Quite possibly both parts are really waiting for a third node: a decision about the shared states and the error format. The form-and-API example is worked through in full in the worked cycle example.

Fan-out, fan-in and the integration owner

One decision can open several independent paths. This is fan-out: once the schema is agreed, work on persistence, the server contract and the error text can each begin separately. Several branches can converge on one result. This is fan-in: the integration check needs every part that makes up the scenario.

Moment	Prerequisite	Work after it	What the convergence produces
Fan-out	Response contract agreed	Server implementation; client preparation; documentation update	An agreed candidate for each required part
Fan-in	Server and client ready against the shared contract	Integration check	The server's actual response and the client's behaviour, together
Fan-out with access	Test-provider account granted	Booking-write check; timeout check; retry analysis	An agreed conclusion about the real environment

A fan-in point needs an owner. If every worker separately reported "done" but nobody connected the two sides and checked their joint behaviour, the work has not been integrated. Node readiness means their results and evidence, not the number of completion messages.

Not every fan-out justifies starting all possible work at once. It takes people, context, environments and the integrator's time. Do not run more work in parallel than the people, the environment and the integrator can support: when simultaneous work creates a review queue or a queue of merge conflicts, the extra workers may only move the bottleneck.

Critical path, duration and slack

The critical path is the longest chain of mutually dependent work, by duration, from the start to a given finish. In a simplified network without resource constraints, the duration of this chain sets the earliest possible finish for the whole set of work. If a node on the critical path slips, the finish date slips with it — unless the team changes the duration, order or scope of the dependent path.

CPM (the critical path method) formalises the calculation of early and late dates and of slack (also called float). PMI (the Project Management Institute) describes a critical activity as one with no total float; delaying such an activity delays the planned finish. Here we use a simplified manual calculation, not a full model of a large schedule.

For the arithmetic, assume the shared API contract was agreed before the clock starts. That decision is not included in the durations below. In the graph, A is a compatible data-storage schema, B is the server API, C is the client interface and D is the integration check. B needs A; C can start in parallel with A and B because the contract is already agreed; D waits for B and C.

Node	Result	Prerequisite	Estimated duration
A	Compatible data-storage schema prepared	None	1 working day
B	Server API implemented against the agreed contract	A	3 working days
C	Booking shown in the client interface against the contract	Contract agreed before the clock starts	2 working days
D	Integrated scenario checked, including access	B and C	1 working day

The early schedule, in working days, looks like this:

Node	Earliest start	Earliest finish	Explanation
A	0	1	Schema preparation
B	1	4	Waits for compatible schema A
C	0	2	Contract already agreed; client can start in parallel
D	4	5	Waits for server B and client C

There are two main chains:

• A → B → D: 1 + 3 + 1 = 5 working days;
• C → D: 2 + 1 = 3 working days.

So the critical path is A → B → D, and the earliest finish is day 5. The client branch C has two working days of slack before the D convergence. Even with an agreed contract, the edge A → B remains: in this example the server implementation cannot finish before the schema.

Speeding up A from one day to half a day would shorten the critical path by half a day as well, provided B and D do not change. Cutting C from two days to one would gain nothing: with two days of slack, integration would still wait for B until day 4. This is arithmetic on the given estimates, not a reason to sacrifice the quality of the API.

Slack and uncertain estimates

The table uses a single illustrative number per node to show the arithmetic. In a real task a duration may be a range. For instance, if work C is estimated at 2–5 days because nobody knows yet how to obtain the current customer, record that risk, the source of the range and the step that will narrow the uncertainty. Do not call "3" precise just because the planner asks for a single value.

In this network the C branch has two working days of total slack; B lies on the critical path and has zero total slack. A separate uncertainty buffer for B is a planning assumption, not calculated slack. Say what unknown it covers, who may use it and when the plan will be reviewed.

The critical path is not fixed either. If B's actual duration grows, the longest path may change. A new integration risk may add a node and change the whole schedule. When a prerequisite changes, the graph is recalculated, rather than continuing to quote yesterday's date.

Two orders for the same work

Let's compare two ways of organising the same four pieces of work. Node A is the physical data-storage schema, not the decision about the contract. The durations of A, B, C and D are 1, 3, 2 and 1 working days respectively.

Without an agreed API contract. In this teaching variant the team prepares schema A, implements server B, builds client C only after seeing the server's actual response, and then checks integration D. This chosen order A → B → C → D takes 1 + 3 + 2 + 1 = 7 working days. It is not the only way a team could behave, and it is not an inevitable consequence of having no contract; the example shows the cost of one particular assumption — that the client must wait for the server implementation before fixing its fields and states.

With a contract agreed before the start. The decision about the response shape was made before the clock started and is not counted in node A or in the schema's duration. Client C can start in parallel with A and B. Server B still needs schema A, and integration D needs both B and C finished. Under these assumptions the critical path A → B → D takes five days, and the client branch finishes earlier. Compared with the sequential variant, the model shows two potentially saved days.

The contract did not create the missing column or remove the migration; it does not produce the data the server needs, and the server cannot always be prepared without the migration. If the API genuinely cannot be implemented or checked without the physical schema A, the edge A → B stays. If the client needs a new decision about errors, name it as a separate prerequisite in the graph or refine the contract; do not hide it in the estimate for B or C. If the server can be written against an approved interface before the migration, change the graph accordingly. This comparison changes only the assumption about the contract — and a parallel start still does not mean finished integration.

Logical dependencies and resource constraints

A logical dependency exists because of the content of the work: a test needs a finished route; a migration needs a settled format; a user-facing message needs a decision about the rule. That order stays necessary no matter how many people are available.

Resource constraints arise from shared capacity:

• one person has to review the changes of two workers, or the decision-owner has limited time;
• only one test environment is available at a time;
• the database has a single, exclusive migration queue;
• the provider allows a limited number of requests;
• two agents edit a shared type or the same file;
• the business decision-owner is available only at certain hours;
• a shared network port or test rig can be occupied by only one process at a time;
• several branches change the same set of test data, or fixtures (prepared test records), so a new data shape breaks another check's assumptions.

These are different models. There may be no edge in the code between two independent changes, yet the calendar does not allow a service or a person to be used by both at once. Conversely, having two workers does not remove a logical prerequisite that does not yet exist.

Worked example: one shared reviewer

All the estimates in this example are invented. Once the contract is approved, two changes can be implemented in parallel:

Work	Implementation	Review by one shared reviewer
A: server contract test	1 day	2 days
B: persistence change	2 days	2 days
I: joint integration check	1 day	Starts after review of A and B

The clock starts after the contract, and implementation of both changes begins on day 0: A is ready on day 1, B on day 2. A single reviewer reviews A from day 1 to day 3, then B from day 3 to day 5; integration point I takes another day, so the graph finishes on day 6. Two reviewers with the right context, working at the same time, could review the changes in parallel, finish B's review on day 4 and integration on day 5.

These days are not a forecast for a real team. They show that a resource constraint adds a real queue even though the two changes do not logically block each other. A real reviewer might not review A and B strictly in sequence; if so, the graph should be refined. An approval on a review does not prove that independent branches are compatible: only the joint integration check shows that. Do not plan ten parallel agent branches if behind them there is only one integrator and one convenient review window.

Hidden links and architectural coupling

Two nodes can have different names yet change a shared type, schema, rule or external contract. If the server changes its response format and the mobile client, the web interface and the test suite all read it, those parts are coupled, even though each lives in a different directory.

In Software Architecture: The Hard Parts, Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani look at coupling through the effect a change has on other parts of the system, and compare contract options. Splitting a system into smaller services does not remove coupling by itself: shared data, transactions, contracts and message ordering can simply carry it across the network. So before drawing up a schedule, don't ask only "which team owns this component?" Also ask:

• who reads the field or the event;
• who defines the source of truth and the lifecycle of the state;
• which versions can exist at the same time;
• where compatibility is checked;
• who has the right to roll the change back;
• what a repeated request, a missed event or a partial failure leads to.

A shared contract can reduce the hand-over of assumptions and let work on the consumer and the provider go ahead in parallel. It does not prove that the actual implementations agree: the integration check is still needed. A test double reproduces the contract only as far as it itself matches the agreed schema and the real service.

Do not automatically add an edge between every two parts that happen to touch the same system. Write down the specific change that could propagate and the check that would catch it. Otherwise the graph stops distinguishing important prerequisites from the general fact that "everything is connected in the end".

Brooks, human coordination and the agent analogy

In The Mythical Man-Month, Frederick P. Brooks Jr. warns against the naive assumption that extra workers shorten software work in proportion to their number. He separates the time needed to bring people up to speed on the context from the cost of communication and of coordinating the parts. Tasks also have an indivisible core: defining a shared concept, deciding a rule or agreeing a contract boundary is not sped up by simply duplicating workers. Robert L. Glass's retelling of Brooks's law likewise links the delay caused by adding people to the time spent on training and communication.

This explains why having several agents does not mean every node of the graph should be started at once. Imagine several agents independently naming the same states differently: instead of parallelism, the team gets three fast implementations and new reconciliation work. One short agreement may be needed first, after which the parts genuinely can be split.

There are limits to the analogy. Brooks described human work in the software projects of his time. His observations cannot be carried over directly to modern artificial intelligence (AI) agents as a quantitative law. Learning speed, context size, the way results are handed over and tool constraints all differ. The limits of the analogy are discussed further under small batches and coordination. Use the idea as a question to put to the plan: how many new links needing agreement will one more worker create, and how will that worker receive the agreed decision?

Team Topologies analyses the flow of work and the ways teams interact: temporary collaboration to discover boundaries, providing a capability "as a service" with a clear owner, or facilitation — helping another team with a specific obstacle. It is a model for organising human teams, not an algorithm for building a code graph. For agents it can be applied only as an engineering analogy: to identify where a short joint exploration is needed, where there is a stable contract between producer and consumer, and where an agent should help clear a blocker. Such a transfer is not researched evidence of an agent group's productivity.

Shared and indivisible results

Examples of nodes that often need a single decision-owner:

• the meaning of statuses and the permitted transitions;
• who owns the truth about a booking's date;
• the cancellation or refund policy;
• the error format that the server and the client handle consistently;
• an access restriction that must hold regardless of the interface.

These must first be fixed in one decision. After that, the implementation can be split into several nodes. If such a decision is handed to several workers without a shared artefact, the problem does not go away — the assumptions simply multiply and come back as contradictions. So before fanning out, agree the statuses, the source of truth, the cancellation and refund rules, and the shared contract for errors and access.

Worked example of a cycle: the form waits for the server, the server waits for the form

Imagine the team has written down two prerequisites:

• the client screen cannot be finished until the server provides the shape of its response and errors;
• the server route cannot be finished until the screen defines all the messages and transitions.

If both uses of "finished" mean the same state, the graph contains a cycle: server → screen → server. Neither node can finish first.

The fix is to separate the shared decision about the contract from the final implementation:

Node	Result	Depends on
C: agree a minimal contract	The success, no-booking, access-denied and error states; the data fields	A decision by the product owner and the API owner
A: implement the route	Responses that follow the contract	C
B: build the screen	Interface states for the same responses	C
I: check the scenario together	Actual compatibility of the server and the interface	A and B

Now there is no cycle: C → A, C → B, and A and B converge in I. During implementation the wording of messages may be refined; if a new decision changes the contract, update C and check the impact on both consumers. Do not take this as proof that the contract was unnecessary: it was precisely what gave both parts a workable starting boundary.

Another way out is to state that the dependency actually concerns only testing, not starting work. Then the interface can be built against an agreed sample response, the server can follow the defined contract, and integration happens later. But do not call the separate parts finished if a new agreement has changed their actual behaviour and the check has not been repeated.

Updating the graph when something unknown turns up

A plan is a working model, not a promise that no new links will appear. Suppose a check reveals that the calendar provider does not support atomic rescheduling. What depends on that may not be viewing a booking at all, but only the separate scenario of changing its time. The discovery should create a new node with a question, an owner and a decision about which parts it affects.

To update the graph:

1. Record the fact separately from the assumption. "The provider does not return a final state after a timeout" is an observation; "we need to rewrite the integration" is a conclusion still to be tested.
2. Name the consumers of the result. Which features are waiting for this decision? Which can carry on?
3. Clarify the type of link. Is a contract, a permission, a test environment, a resource or merely a preferred sequence needed?
4. Add a node or change an edge. Don't hide a new prerequisite in a single comment on an old change request.
5. Find the owner and the evidence. Who answers the question, and what will show that the answer has been obtained?
6. Recalculate the critical path and the slack. If work was added or an estimate changed, the old date no longer comes from the current graph.
7. Tell the workers the change affects. If an agent keeps working against the previous contract, its output may become rework.

Not every new observation changes the plan. If a check shows that a postponed feature does not affect the current slice, record that as a confirmed absence of an edge, rather than holding up all work "just in case".

A minimal written dependency record

Even without a dedicated planning tool, a team can keep a short record:

Field	What to record
Node and result	A short identifier and the work to be finished
Prerequisite and link type	A result, decision, access, contract, resource or preferred order; write "none" if there is no prerequisite
Readiness	The observation that confirms the prerequisite
Owner	Who is responsible for the result
Resource	A shared person, environment or provider
Parallelism	What can start, and what must wait until it is checked
Integration	Who connects the parts, and against which scenario
Uncertainty	The duration range and its reason, if that helps a decision

For the fictional booking graph, a short record might look like this. The response contract was agreed before this plan began and is not a node; the edge A → B remains because of the storage schema:

Node	Prerequisite	Can start	When it is ready
A: compatible storage schema	Confirmed access rule	After the owner's decision; in parallel with C	Migration verified on the old and new versions
B: server API	A; agreed response contract	After A	The route follows the contract and checks the owner
C: client interface	Agreed response contract	Can start in parallel with A and B	Positive, empty and error states shown without leaks
D: integration	B and C	After both candidates	The joint scenario has passed on the connected parts

For A, B, C and D, the table thus shows, in turn: the migration check on old and new versions; the API's conformance to the contract and its ownership check; the positive, empty and error states shown without leaks; and the joint scenario passing on the connected parts. The full set of fields for an implementation plan is covered under the minimum record you can hand to someone else; this record exists only for prerequisites, resources and the integration point.

Such a table is not a homework exercise or a substitute for automation. It is a working record of prerequisites and evidence. If the team renames a task but does not update its result and prerequisite, the table stops helping. If the table grows large and nobody can see where the integration point is, that is a signal to simplify the model or split it by result.

An open-source example: a GitHub Actions graph

In FastAPI's test.yml file, pinned to a specific commit, the changes node checks which paths have changed; the test and benchmark jobs depend on it, and test expands into a matrix of operating systems, Python versions and dependency sets. So one shared upstream node fans out into several checks, and one job fans out into matrix variants. This is a real example of a technical graph of CI (continuous integration) checks — not a graph for developing a product scenario, and not FastAPI's internal schedule.

The official GitHub Actions documentation defines the needs field as the way to name jobs that must complete successfully first; when several prerequisites are listed, the next job waits for all of them. By default, if a job it depends on fails or is skipped, the dependent jobs are skipped too, unless a condition overrides that rule. The configuration file itself has only a few nodes, so it is worth reading alongside the documentation.

The configuration confirms the launch order and the propagation of skips and failures only for the edges explicitly declared in this workflow. It does not prove that any large software project can be planned precisely in advance.

Launch agents by the graph, not by the number of slots

Launch only those agent tasks whose prerequisites and resources are ready. Before fanning out, check that each parallel piece of work has:

• a clear result and exclusions;
• the decision or access it needs;
• a shared contract, if another part consumes its result;
• limits on shared files, migrations, test environments and other resources;
• an owner who will check the integration;
• a criterion by which the result can be accepted.

Leave short dependent steps to the coordinator, and coordinate changes to shared files between workers. Watch for new dependencies while the work is under way: if a shared type appears, agree it first, update the graph and hand the same contract to every consumer. If several parts need a shared type or contract, agree it before parallel implementation, and then check the result on the connected parts.

The integration owner reads more than the final messages: they reconcile the actual changes, the results of automated checks, the order of migrations, the error logs and the joint scenario.

Prerequisites differ by stage. An agent can begin a contract-bounded implementation of a route before the migration, but it cannot prove the new table is compatible with the data until an environment is available. Distinguish "can be written", "can be checked", "can be merged" and "can be switched on". If the test environment, the data or the permission is missing, call the check unfinished; a worker's confidence does not create evidence of compatibility.

OpenAI's official Multi-agent documentation recommends giving parallel agents independent, bounded tasks with a clear question and result; this is the recommendation of a particular orchestration tool, not proof that parallelism always speeds a team up.

When the graph needs to be replaced or supplemented

A graph shows logical sequence, but other problems may call for separate decisions and for tracking resources:

• If the main unknown is which option the customer needs, design a short piece of research or a product decision first.
• If every task is waiting on the same provider, it is more useful to describe the integration owner and the external readiness separately.
• If the team has too many parallel changes and a review queue, measure work in progress and capacity instead of adding edges without a reason.
• If the requirements change after every observation, update the graph together with the result boundaries, rather than freezing it for an appearance of precision.
• If the blocker is a decision for a manager, add that owner to the node; an arrow will not make the decision by itself.
• If tasks are deliberately done in stages with reassessment, show the next decision as a gate, rather than pretending that all future dependencies are already known.

A graph is not an exact forecast of the future. It is a checkable explanation of which result holds up another under the current assumptions; its value lies in the fact that those assumptions can be discussed and updated when a new fact appears.

Summary

A graph runs from a prerequisite to the work that consumes it, and shows fan-out, convergence points, the critical path and slack — but on its own it does not capture resource queues. A reviewer, a test environment, access, a provider and people's context can each create separate resource or organisational constraints. A cycle often points to a missing shared decision or to a badly phrased requirement about starting versus finishing; name the decision you need before parallel work begins. When a new dependency appears, update the graph, the estimate and the expectations of the workers it affects. Before launching work, check prerequisites, resources, shared files, the integration owner and the evidence of completion. Brooks's ideas and the Team Topologies models help us talk about coordinating human work, but carrying them over to AI agents remains an analogy, not a law. Implementation plans bring these decisions together into a plan of work.

Sources and further reading

The materials were checked on 23 September 2026; the current examples and documentation were re-checked on 26 September. All days and estimates in the examples above are invented. Applying planning principles to AI agents is marked as a teaching analogy from engineering.

1. Ryan Singer, Shape Up: Stop Running in Circles and Ship Work that Matters, Basecamp web book; accessed 23 September 2026. Chapter read: "Map the Scopes". The author treats scope boundaries (separate areas of work) as something discovered from the real links within the work, not only from the roles of the people doing it; the boundaries may be refined along the way.
2. Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani, Software Architecture: The Hard Parts, chapters "Discerning Coupling in Software Architecture" and "Contracts", O'Reilly Media, October 2021; accessed 23 September 2026. Based on the publisher's available preview and the contents of the chapters on coupling, contracts and distributed processes; the full text of the book was not read. The topics attributed to these chapters are supported by the contents and the publisher's preview; the examples in this unit are a teaching synthesis.
3. Scott W. Kramer and James L. Jenkins, "Critical path method calculations: Understanding the basics of CPM calculations", paper presented at PMI Global Congress 2006—North America; accessed 23 September 2026. Explains dependencies, durations, early and late dates, float and the critical path. This unit uses a simplified manual example, not full schedule planning.
4. GitHub, Using jobs in a workflow, current GitHub Actions documentation; accessed 26 September 2026. Describes job prerequisites via the needs field and how subsequent jobs behave after a dependency fails or is skipped.
5. FastAPI contributors, test.yml workflow file, an open automation configuration file in the FastAPI repository; accessed 26 September 2026; the link is pinned to commit 50113da16fec53b66b80d75e80a89296de4fa5a5. Shows that the test and benchmark jobs wait for changes to finish, and that test runs a matrix of environment combinations. This is evidence about one open repository's configuration at the time it was viewed, not a general development graph for the project.
6. Matthew Skelton and Manuel Pais, Team Interaction Modeling with Team Topologies, official Team Topologies material; no page update date given; accessed 23 September 2026. Describes collaboration, providing a capability "as a service" and facilitation as modes of team interaction, and discusses cognitive load. These organisational models are not a direct algorithm for planning the nodes of a software task.
7. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 20th anniversary edition, 1995; accessed 23 September 2026. The publisher's bibliographic record and a legal 22-page sample of publisher pages with the book and chapter contents were reviewed. The full chapter "The Mythical Man-Month" was not read here; the reference to the argument about training and coordination is a cautious reminder of the book's concept, not an assessment of modern teams or agents.
8. Atlassian Support, Link work items and Create or remove dependencies on your timeline, Jira Cloud documentation; accessed 23 September 2026. Distinguishes "blocks/is blocked by" links from a timeline dependency, in which the prerequisite must finish before the next piece of work starts; an administrator can configure the available link types.
9. OpenAI, Multi-agent, current OpenAI Agents API documentation; accessed 26 September 2026. Recommends parallelising independent tasks with a clear result, leaving dependent steps to a coordinator and coordinating agents' work on shared files. This is documentation of product behaviour and a vendor recommendation, not an independent measurement of speed-up.
10. Robert L. Glass, "People," Facts of Software Engineering Management, InformIT, 22 November 2002; accessed 26 September 2026. This excerpt from the book Facts and Fallacies of Software Engineering retells Brooks's law and explains the costs of training newcomers and of communication in a human team. It is a secondary account, not a claim about the productivity of AI agents.