DraftThis concept page is in progress. Discovery Agent and the knowledge graph are shipped; the polished cross-product upload-to-backlog flow shown here is the next refinement.

Connected Artifacts, Designed

Upload one document. Watch the platform reason across everything you’ve built.

The unified knowledge graph is the bet underneath everything in ProductIntel. Stories, docs, cases, requests, APIs, learned heuristics — same artifact type, same edges, same queryable graph. The point of the bet is not the data model. It is what becomes possible when AI can reason across all of it at once.

What follows is one designed example of what that reasoning looks like. A single document in. Three product-aware recommendations out. Five minutes from upload to a queued backlog of work units that already know which files to touch in which product.

The Scenario

One PM manages three products built on the same ProductIntel instance: Easycomm, Acme CRM, and Acme Insurance. They drop a single document into the platform — the Postmark v4 API release notes — and let the Discovery Agent loose on it. What follows is what happens when every artifact in the system already lives in the same graph.

01Stage · UploadMon · 10:14 AM

One file. Drop it in. Tell the platform what to do with it.

ProductIntel · Discovery Agent · Intake

Drop a doc to discover

API specs, changelogs, RFCs, design notes. The agent decides what to do with it.

postmark-v4-release-notes.md

38 KB · Markdown · API release notes

✓ Ready to process

Discovery action recognized

This looks like an API release notes doc. Recommended action: scan all enabled products for upgrade and opportunity matches. The agent will read your codebase against the changes and surface per-product recommendations.

Easycomm
Acme CRM
Acme Insurance

What humans do

Drags the API doc into the Discovery Agent intake. Confirms scope (which products to consider) — defaults to all enabled products.

What AI does

Recognizes the document type (API spec / changelog / design doc), surfaces an appropriate Discovery action, requests confirmation before doing anything irreversible.

02Stage · ReadMon · 10:14 AM (≈ 45 sec)

Discovery Agent reads the doc. Then reads your codebase. Then reads itself.

ProductIntel · Discovery Agent · Reading

Discovery activity

⬤ RUNNING · 23s elapsed

+0sdiscoveryDocument received · postmark-v4-release-notes.md · 38 KB
+1sparserIdentified 9 endpoint changes · 4 new features · 2 breaking changes · 1 deprecation
+4sgraphQuerying knowledge graph for artifacts mentioning Postmark, transactional email, template engine, sender authentication
+7sgraph47 candidate artifacts retrieved across 3 products
+12scodeCross-referencing against repository indexes · easycomm/, acme-crm/, acme-insurance/
+18scodeEasycomm · 2 files use Postmark v3 SDK · last touched 14 days ago
+22scodeAcme CRM · 3 files use Postmark v3 SDK · 1 file uses sender pool ID
+24scodeAcme Insurance · no Postmark dependency · case digest cron uses Resend (mismatched scaling)
+31sagentSynthesizing per-product implications · classifying edge types
+38sagent3 connection types detected: direct upgrade · upgrade-plus-feature · opportunity gap
+42sagentDrafting recommendations · grounding each in concrete file paths and existing patterns
+45sagentDone · 3 product-specific recommendations ready · ~$0.04 in tokens

What humans do

Watches a short activity log and waits. There is nothing to decide here yet.

What AI does

Parses the API spec into a structured shape (endpoints, methods, breaking changes). Queries the knowledge graph for any artifact that mentions related concepts. Cross-references against existing code in each product.

03Stage · ConnectMon · 10:15 AM

The graph lights up. Three products. Three different kinds of connection.

ProductIntel · Discovery · Connections Detected

Knowledge graph · new edges materialized

12 edges · 3 typed relationships

Easycomm

Direct upgrade

2 files · Postmark v3 → v4 SDK

Acme CRM

Upgrade + feature

3 files · v3 → v4 + new sender authentication API

Acme Insurance

Opportunity

0 files · case digest could use v4 batching for high-volume sends

postmark-v4

→ Direct upgrade — files already use v3, mechanical migration

→ Upgrade + feature — existing usage maps to new capability

→ Opportunity — net-new applicability, no existing dependency

Why three different edge types matter

A flat “here are matches” list collapses very different kinds of work into one bucket. The graph distinguishes them so the recommendation phase can shape each appropriately. Direct upgrades become small mechanical stories. Opportunity gaps need product judgment before they become work.

What humans do

Reviews the detected connections. Can prune anything that looks wrong before recommendations are generated.

What AI does

Materializes typed edges in the knowledge graph between the new API doc and existing artifacts. Different edge types: direct dependency, pattern match, opportunity gap.

04Stage · RecommendMon · 10:16 AM

One recommendation per product. Each grounded in what already exists.

ProductIntel · Discovery · Recommendations

Per-product recommendations · 3

All grounded in existing code

Easycomm

Migrate digest emails from Postmark v3 SDK to v4

Mechanical SDK upgrade. v4 collapses two send calls into one and adds the new template engine. No behavior change for end users.

Files anchored

  • · easycomm/lib/services/digest.ts
  • · easycomm/lib/services/notifications.ts

Size · Verdict

Small · ~14 LOC delta

Agent team can take this

Acme CRM

Migrate to Postmark v4 + adopt new sender authentication API

Direct SDK upgrade plus a real feature opportunity: v4 sender auth eliminates the per-domain DKIM verification flow your sales team currently does manually for new clients.

Files anchored

  • · acme-crm/lib/email/postmark.ts
  • · acme-crm/lib/services/sender-pool.ts
  • · acme-crm/app/admin/senders/page.tsx

Size · Verdict

Medium · ~80 LOC + admin UI changes

Hybrid: agents take SDK upgrade, humans take admin UI

Acme Insurance

Replace Resend with Postmark v4 for case digest cron (opportunity)

Acme Insurance does not use Postmark today. The case digest cron is on Resend, which has been throttling at month-end. Postmark v4 batching would handle the load cleanly. This is an opportunity, not a forced migration.

Files anchored

  • · acme-insurance/app/api/cron/case-digest/route.ts (read for context)
  • · New service: acme-insurance/lib/email/postmark.ts

Size · Verdict

Medium · greenfield service + cron rewrite

Needs PM judgment · effort vs Resend pain

What humans do

Reads the three recommendations side by side. Adjusts scope, accepts, or sets aside any of them.

What AI does

Synthesizes per-product recommendations from the connected edges. Each recommendation includes the type of work, the existing code it touches, the rough size, and the why.

05Stage · QueueMon · 10:18 AM

One click. Three work units land in three product backlogs. Already anchored to code.

ProductIntel · Work · Backlog · Filtered to Discovery-sourced

New work units · pushed from Discovery

✓ 3 of 3 created · linked to source doc

EC-PB-318Easycomm

Migrate digest emails from Postmark v3 SDK to v4

agent-teamsmallmechanicalDiscovery · postmark-v4-release-notes.md
AC-PB-204Acme CRM

Migrate to Postmark v4 + adopt new sender authentication API

hybridmediumadmin-uiDiscovery · postmark-v4-release-notes.md
AI-PB-091Acme Insurance

Evaluate Postmark v4 for case digest (Resend replacement)

needs-pmmediumgreenfield-serviceDiscovery · postmark-v4-release-notes.md

Lineage preserved

Each work unit links back to the source doc and to the existing files it touches. When an agent or a human picks one up, the spec, the API doc, and the relevant code patterns are already in context. No re-discovery needed.

What humans do

Clicks ‘Push all to backlogs’. Reviews the result in the unified backlog view. Tags or schedules as needed.

What AI does

Creates the work units against each product’s backlog with team tags, file anchors, and the original doc as a parent reference. Each work unit is already refined enough to be picked up by an agent or a human in the next sprint.

Five Minutes, Three Products

This works because every artifact lives in the same graph.

In a federated stack, this story does not happen. The API doc lives in Confluence, the existing integrations live in code that nobody indexed for AI, the products live in different Jira projects, and the cross-product reasoning has to happen in someone’s head over the course of a week. Most weeks, it does not happen at all.

The unified graph is a small architectural choice that pays off in surprising places. This is one of them. The Knowledge Chat answering a question that spans three products is another. The Discovery Agent finding a backlog cluster from a customer case is another. Same graph, different expressions.