Subgraphs and multi-agent graphs

Overview

• A subgraph is a smaller graph used as a component of a larger one.
• A multi-agent graph assigns model-driven responsibilities to separate nodes or subgraphs.
• Subgraphs support modularity even when no multi-agent behavior is involved.

Why this matters

Different domains may need separate state contracts, tests, and ownership.

An everyday example

A department follows its own checklist but reports a clear outcome to the larger company process.

A technical example

A policy-answer subgraph returns {answer, sourceIds, answerable} to a customer-support graph.

How it works

1. Map parent input
2. Run subgraph with scoped tools/context
3. Map bounded output
4. Combine results under parent policy.

Architecture and flow

Parent graph → typed subgraph boundary → domain steps → validated parent update.

The insurance assistant example

Claims and policy specialists share verified IDs but not unnecessary customer documents.

When to use it

Reusable domain workflows and independently owned responsibilities.

When to avoid it

Avoid a subgraph for every trivial function or unrestricted recursive delegation.

Interview answer

“Subgraphs modularize stateful processes. I define narrow input/output contracts and scope their tools and persistence deliberately.”

Benefits, trade-offs, and production considerations

• Test checkpoint namespace behavior, error propagation, shared state mapping, and concurrent updates.
• A specialist does not gain extra permissions merely because a supervisor called it.