Render financial, news, and technical findings differently

Learning objective

Render financial findings as tables, news as prose, and technical results as structured lists when appropriate.

Core idea

A synthesis report needs more than accurate sentences. It must expose the relationships the reader needs to inspect: values across periods, events through time, and technical properties under stated conditions. One uniform format can hide those relationships even when the underlying evidence records are complete.

For an architect building a multi-agent research system, specify output form in the synthesis contract. Use financial tables for comparison, news prose for an event narrative, and structured lists for discrete technical findings. Keep attribution and qualifications through that presentation change; attractive formatting cannot substitute for supported content.

How it works

Use this mapping to choose the form while preserving the evidence needed to interpret it:

Choose the form by the reader’s comparison

Financial findings often require readers to compare values, units, periods, and definitions. Put those dimensions in columns so a reader can inspect the basis of each number. A table with a value column alone is insufficient when the rows use different currencies or reporting periods.

The following table uses hypothetical figures solely to illustrate a reporting contract:

The forecast remains visibly different from the actuals. The evidence identifiers resolve to the source records preserved in 5.6.1. In a delivered report, render those identifiers as usable references or include a clearly labeled source key, rather than leaving the reader with unexplained internal codes.

Retain methodological differences instead of normalizing them away to make columns align. If two figures use different definitions, label the basis and explain whether comparison is valid. A financial table should expose disagreement or a time-series limitation, not manufacture comparability.

Preserve chronology in news prose

News findings need dated prose when the relationship between events matters. Distinguish an announcement, a later decision, and an effective date. Attribute the report and retain whether a statement is confirmed, proposed, or conditional. A publication date alone does not establish when the event occurred; see 5.6.2 for the separate clocks.

For a hypothetical service announcement, a useful paragraph says that the supplier announced a proposed pricing change on one date, that customer approval remains pending, and that the proposed effective date falls later. A flat list of three dates can lose those relationships. A single sentence saying that prices changed would overstate the evidence.

Use prose to connect only the relationships supported by the sources. Sequence is not proof of causation. If a company announcement follows a market event, the report should not claim that the market event caused the announcement unless the evidence supports that explanation.

Make technical findings independently inspectable

Technical findings often work as structured list items, each containing a property, result, conditions, and evidence reference. A reader can inspect an individual capability without extracting it from a dense narrative. Keep test configuration and limitations beside the result they constrain.

For example, a hypothetical technical section might contain:

• Latency: A measured percentile under the stated workload and concurrency, with the benchmark evidence reference.
• Recovery: The documented recovery procedure and the tested failure condition, with the incident or test evidence reference.
• Compatibility: The tested interface version and excluded configuration, with the source passage supporting the scope.

These are content requirements, not universal fields defined by Anthropic. The list should contain the actual supported findings, not empty labels filled with plausible guesses. If a comparison across many products becomes the reader’s main task, a technical comparison table can be more appropriate. The objective’s pairings guide the decision rather than banning all other forms.

Specify the mixed output positively

Anthropic’s prompting guidance recommends explicitly describing the desired format, using positive instructions, and providing examples to steer structure. Put the mixed-format requirement in the synthesis agent’s AgentDefinition.prompt: financial comparisons use tables, news uses dated prose, and discrete technical results use structured lists, with evidence and qualifiers retained in every form.

Give the specialist an example layout that matches the desired report. Avoid supplying an all-bullet example and expecting it to infer that the financial section should become a table. Require the evidence-status distinctions from 5.6.4 independently of format: a disputed financial result can have its own comparison table, while an under-researched technical question remains visibly unresolved.

Native Messages API citations can attach evidence to response text blocks. Preserve the returned citations data when your application renders the response. Do not assume that displaying a paragraph or table automatically displays its sources. If your pipeline instead uses application-defined evidence identifiers, resolve those identifiers during rendering and verify that every displayed claim retains the right references.

Key distinctions and trade-offs

Output form versus output guarantee: A prompt requesting Markdown tables guides presentation. It is not the same mechanism as schema-constrained JSON output. Native citations are incompatible with output_config.format; see 5.6.1 before combining evidence capture with strict record generation.

Classification versus presentation: Well-supported, disputed, and under-researched describe evidence status. Table, prose, and list describe how information is displayed. Keep both dimensions rather than treating a polished table as a sign of certainty.

Consistency versus uniformity: A consistent report preserves source keys, dates, and qualifiers everywhere. It need not force every section into the same visual form. Mixing forms is useful when each supports a different reading task.

Tables favor comparison but can compress narrative context. Prose supports chronology but can bury numbers. Lists expose discrete results but can obscure relationships between them. Choose the form that makes the relevant relationship easiest to inspect.

Architecture / decision scenario

A coordinator prepares a fictional supplier assessment containing revenue figures, a service launch announcement, and benchmark results. The evidence records already include dates, source locations, and qualifiers. The coordinator passes those records and its uncertainty decisions to the synthesis specialist.

The report presents revenue by fiscal year in a table, preserving currency and distinguishing actuals from forecasts. It describes the service announcement in prose, separating the announcement date from the proposed launch date. It presents benchmark properties as structured items, keeping workload conditions with latency and recovery results.

During review, the coordinator finds that a table row dropped a forecast assumption and a news paragraph converted a proposed launch into a completed event. It returns those specific claims for correction against the source records. The final rendering retains citations and shows the unresolved recovery-test gap as such. The mixed format makes the report easier to inspect while preserving exactly what the evidence supports.

Common exam traps

• Converting every source into the same paragraph or bullet template.
• Displaying financial values without periods, units, or source references.
• Presenting a forecast in the same way as a measured actual.
• Confusing an announcement date with an effective date.
• Removing test conditions from technical list items.
• Treating mixed-format prompting as an automatic evidence-validation mechanism.

What to remember

Render financial comparisons as tables, news relationships as prose, and discrete technical findings as structured lists when those forms fit the task. Specify the layout positively and keep evidence, dates, uncertainty, and methodological qualifiers in every form. Presentation should reveal the structure of the evidence rather than simplify it away.

Knowledge check

References

• Anthropic, Prompting best practices
• Anthropic, Subagents in the SDK
• Anthropic, Citations