Three agents finished their tasks. How do you turn them into one deliverable?
Align source keys, units and versions before a writer turns parallel work into a report.

Research has twenty sources, analysis has a spreadsheet, and the writing agent has a polished draft. The report still cannot be delivered: the revenue figure uses a different period, the competitor name is ambiguous, and two citations point to an older file.
Parallel agents reduce waiting only when their outputs can be joined. Multi-agent deliverable integration needs an agreed input contract, a dependency order and a person responsible for the final artifact—not three independent completion messages.
Freeze the question before splitting the work
Consider a fictional market report for two demonstration companies, Cedar and Harbor. The reader is an operations lead deciding which market to investigate next. The scope is one region, a defined reporting period and publicly available evidence. The example files below illustrate a method, not actual company research or efficiency results.
Write a single brief.md: audience, decision, geography, cutoff date, currency convention, observation window, required sections and output files. Specify excluded work, such as contacting companies or writing to a production database. A source published after cutoff does not quietly enter the current edition.
Name the integration owner—a role actually assigned by the team. That person decides scope and resolves competing interpretations. The writing agent does not gain authority to decide commercial strategy merely because it produces the final prose.
Parallelize independent work, not missing dependencies
Research can build sources.csv while an analyst prepares the schema and permitted calculations. Analysis using the source values waits for the accepted research packet. The writer can prepare section headings early, but factual drafting waits for accepted sources and metrics.
A simple dependency sequence is brief → source packet → accepted metrics → draft. Public-source discovery and template preparation can overlap. Claim-bearing paragraphs should not be written from a hoped-for future spreadsheet.

Give each artifact joinable fields
A source index needs source_id, entity_id, URL, publication date, fetched date, observation window and the supported claim_id. A metrics table needs metric_id, entity_id, source_id, value, unit, currency, period, calculation and version. The draft references claim and metric IDs rather than an untraceable “latest figures” file.
For example, hypothetical rows might be:
metric_id,entity_id,source_id,value,currency,unit,window,claim_id
M1,cedar-demo,S1,12,USD,million,2025,C1
M2,harbor-demo,S2,9000,EUR,thousand,2025,C2
Both values are invented. Converting 9,000 thousands to 9 million changes the unit, not the currency. The two rows are not ready for a revenue ranking. Supply an approved exchange rate and date, retaining original values and formula, or present each currency separately. Different periods require an explicit comparability decision too.
Use stable entity IDs: two companies sharing a display name must not collapse into one. A URL alone is not a join key for every claim on a page; preserve the source passage or table location supporting each claim.
Share accepted copies, not assumptions about access
Drive and memory distinguishes one Agent's private working files from a Space Drive shared across the Space. Separate agents may maintain private inputs; exchange only authorized, redacted copies through the shared location or a deliberate human handoff.
A Session separates conversation context. Multiple sessions of one Agent still use its Drive; session isolation is not a new file-access boundary. A folder named approved does not enforce approval either.
Tell each agent which exact version and files it may read. For example: “Read shared/market-report/v2/sources.csv; do not read v1 or private customer records.” Check actual sharing settings. Paths express a workflow convention, not automatic coordination, locking or permission enforcement.
The manifest makes handoff inspectable
Save manifest.csv beside the packet. Each row names the artifact path, version, generation timestamp, responsible role, dependencies, readiness and missing items. A hypothetical release might contain:
| Artifact | Version | Depends on | Ready when |
|---|---|---|---|
| sources.csv | v2 | brief v2 | Every claim has an entity and source location. |
| metrics.csv | v2 | sources v2 | Units, periods and calculations are explicit. |
| conflicts.md | v2 | sources + metrics v2 | Contradictions and required decisions are visible. |
| report.md | draft v2 | accepted inputs v2 | Claims link to the accepted packet. |
Record actual timestamps rather than copying a template time. “Ready” is a workflow value, not an automatic product certification. The integration owner checks it before instructing the writer.

Resolve data format before resolving meaning
Unit conversion can be deterministic when the input and formula are defined. Conflicting meanings cannot be averaged away. If one source counts paying customers and another counts all registered accounts, keep both definitions in conflicts.md; do not create an average customer count.
For each conflict, record affected claim IDs, both passages, dates, the missing distinction and the decision needed. The owner may choose one relevant definition, narrow the conclusion or exclude the comparison. The writer reports the accepted decision, not whichever number sounds more impressive.
A useful integration instruction is:
Read only the manifest's accepted source and metric versions.
Check entity IDs, source keys, dates, units and calculation references.
Produce report.md plus conflicts.md; retain unresolved claims as questions.
Do not invent missing files, average conflicting definitions or change scope.
Do not send the report or write to an external database.
Changed inputs invalidate specific conclusions
After metrics v2 is accepted, a new source changes C2. The owner marks the paragraphs and chart depending on C2 for revision. Unrelated sections remain intact. This is a maintained dependency list, not a claim that editing Drive automatically refreshes every output.
Keep the old edition and a change note. Regenerate affected text against the new accepted packet, then recheck source keys and numbers. Final delivery includes report.md, sources.csv, metrics.csv and conflicts.md, plus the manifest. The person accepting the report evaluates the business conclusion and unresolved decisions.
Try four broken packets before expanding
Recommended acceptance samples: one missing file should produce a missing-item list, not invented content; an older version should be rejected against the manifest; same-name entities should trigger disambiguation; different currencies should retain originals and require a conversion decision. These are proposed tests, not a completed team pilot.
The Agent Workspace holds role-specific work and reviewable artifacts. The dynamic workflow guide explains the broader operating model. An actual report still needs the file contracts and handoff order described above.
Would one agent be simpler?
Often, yes. Use one Agent with separate Sessions when the task is small and context is largely shared. Split specialists only when their independent outputs have clear boundaries and the integration cost is justified.
How do experts exchange files?
Use authorized Space Drive copies or explicit handoff. Confirm access, source version and permitted use. A private Agent Drive is not automatically visible to another Agent.
Can writing continue when an expert is unfinished?
Only on sections with complete accepted dependencies. For the rest, wait or explicitly reduce scope and label missing evidence. Do not replace absent metrics with plausible prose.
Start with one internal report and three controlled specialist outputs. The goal is not maximum concurrency; it is a final artifact whose numbers, sources and decisions survive handoff.