The Digital Thread Agent
Requirements, documents, CAD, parts, structures, changes and suppliers are one graph with typed edges. This agent is the one that walks it sideways — across domains that in most PLM deployments are four separate conversations.
What it is, and what it is not
An agent whose scope is the relationships rather than any one domain. Where the BOM Agent knows structures deeply and the Change Agent knows the change process, this one knows how a requirement connects to a test, to a part, to a supplier, to a document, to an open change.
It is not a search tool. Search finds objects matching a description; this answers questions whose shape is a path — “what depends on this”, “what would break”, “what evidence supports that we verified this”.
It is also not a separate graph. The relationships it walks are the ones the rest of the product writes as a side effect of ordinary work: a document specifying a part, a requirement a test verifies, an approved manufacturer entry, a change touching a revision. Nobody maintains a thread; the thread is what the records already are.
What it actually does
Answers the backwards question. A component goes end of life. Which shipping products contain it, which requirements did it satisfy, which qualifications referenced it, and is there already an open change on any of them? That is one traversal in six directions, and it is a day of work performed by hand.
Traces verification. Given a requirement, which test verified it, at which revision of which part, and does the evidence still apply after the last three changes? This is the question a customer audit asks, and the honest answer is often that nobody knows without a week of reading.
Answers hypotheticals. “If we move to the alternate connector, what else changes?” — the affected structures, the documents that specify the interface, the requirements the change might invalidate, the supplier records involved, each cited at the revision it was read at.
Finds the missing edge. A part with no specifying document. A requirement with no verification. A released structure containing a component with no approved manufacturer entry. These are gaps in the graph, and gaps are usually where the surprises live.
The failure it prevents
A customer asks whether a change made eighteen months ago invalidated the qualification they signed off on. The answer requires knowing what the qualification covered, which revisions were current then, what changed since, and whether any of it touched the characteristics the qualification tested.
In most organisations that question is answered by finding the two people who were there. If one of them has left, it is answered by a week of reading, and the confidence at the end is low enough that the safe response is to re-qualify — which costs more than the original change did.
The traversal answers it in the time it takes to state the question, with every hop cited to a revision. The answer may still be that the qualification is invalid; what changes is that the organisation knows, cheaply, rather than paying for certainty it could have looked up.
How it meets the rest of the product
It reads over resolved structures, so questions about what is in a product are answered under stated conditions rather than against the stored conditional statement. “Which shipping products contain this part” and “which structures mention it anywhere” are different questions, and this agent asks the first one.
The orchestrator routes to it when a question crosses domains, with typed hand-offs and an explicit precedence rule when agents disagree. A question about a structure goes to the BOM Agent; a question about what a structural change would do to a qualification comes here.
Every hop in an answer is cited at the revision it was read at, which matters more here than anywhere else — a four-hop traversal that cannot be checked is a story. Because the underlying traversal is deterministic, a reviewer can re-run it and get the same path back.
How it meets your ERP
The thread does not stop at the boundary of Manufacturing PLM. Objects published to your ERP are nodes in the traversal, flagged as published, and carry the context read back: on-hand quantity, open purchase orders, lead time, supplier record.
That is what makes the end-of-life question answerable in one pass. Which products contain the part, whether any are shipping, how much stock exists, whether purchase orders are in flight, and whether an alternate is already approved on another product — the engineering half comes from the graph and the operational half from the connector, in one answer with both halves cited to their sources.
Values read from the ERP are cited differently from values Manufacturing PLM owns, carrying the source system and an as-of stamp, because a cached read of somebody else's master record is a weaker claim than a resolution Manufacturing PLM can reproduce.
Where the boundary is
It can only walk edges that exist. A relationship recorded in a drawing note, an email, or somebody's memory is not in the graph, and no traversal will find it. That is an argument for capturing requirements and specifications as objects rather than an argument that the answers are unreliable — but it does mean an early-stage tenant gets thinner answers than a mature one.
It also does not judge severity. Forty affected objects come back as forty affected objects with their paths; ranking which three matter is a recommendation it offers separately, with citations, and not a fact it asserts.
Facts
| Scope | The relationships, not any one domain |
| Domains crossed | Requirements · documents · CAD · parts · changes · suppliers |
| Reads over | Resolved structures, under stated conditions |
| Every hop | Cited at the revision it was read at |
| Finds gaps | Missing documents, unverified requirements, no-AVL lines |
| ERP nodes | Published objects, with stock and open demand |
| Orchestration | Typed hand-offs; explicit precedence on disagreement |
| Limit | Can only walk edges that were actually recorded |
Frequently asked
How is this different from search?
Search finds objects matching a description. This answers questions whose shape is a path — what depends on this, what would break, what evidence supports that we verified this. Different question, different mechanism, and the second one is what people actually ask before a change.
Do we have to maintain the thread?
No. The relationships are written as a side effect of ordinary work: a document specifying a part, a test verifying a requirement, an approved manufacturer entry, a change touching a revision. Nobody curates a thread — the thread is what the records already are.
Can it answer an audit question?
Often, yes, and this is where it earns its place. Which test verified a requirement, at which revision, and whether the evidence still applies after subsequent changes — normally a week of reading with low confidence at the end. Here it is a traversal with every hop cited.
Does it see ERP data?
Published objects are nodes in the traversal and carry the context read back — on-hand, open purchase orders, lead time, supplier record. That is what lets one pass answer both the engineering half and the operational half of an end-of-life question.
What if a relationship was never recorded?
Then it is not in the graph and no traversal will find it. A connection living in a drawing note or somebody's memory is invisible here. That argues for capturing specifications and requirements as objects, and it does mean a young tenant gets thinner answers than a mature one.
Does it rank what matters most?
Only as a separate recommendation, with citations, never as an assertion. Forty affected objects come back as forty with their paths and depths. Judging which three matter is exactly the kind of claim that should be visibly an opinion rather than presented as a result.
How does it interact with the other agents?
The orchestrator routes cross-domain questions here with typed hand-offs, and there is an explicit precedence rule when two agents disagree. A structural question goes to the BOM Agent; what a structural change does to a qualification is this agent's question.