Transcript research and momentum briefings
Connect Discovery leads to source-backed research, bounded synthesis, and durable briefing delivery state.
The organizational momentum workflow separates lead collection, investigation and briefing synthesis. Discovery supplies candidate connections; original sources provide evidence. The researcher records source-linked interpretations of decisions, commitments, blockers, resolutions, handoffs, recognition, and incidents relevant to stated values. It does not score energy, disengagement, or individual performance. A correct quotation establishes provenance, not the correctness or usefulness of an interpretation.
Enable the workflow
Deploy Foundry migrations through 0039, the Foundry API, Harness V1, and the compatible Workspace API.
Use a persistent, always-on agent. An existing transcript checkpoint is compatible;
an insight-research checkpoint must not be silently reinterpreted. Grant:
save_research_checkpointlist_evidence,get_evidence,get_evidence_utterances,searchsave_transcript_review,list_transcript_reviewslist_discovery_packets,get_discovery_packetsend_emailsave_output(currently required by transcript capability validation; Jean Grey does not invoke it)
Use the prompt in services/foundry/prompts/organizational-momentum.md. Configure
WORKSPACE_URL and INTELLIGENCE_URL using the existing deployment configuration.
The effective grants, catalog schemas, and executors are checked before research.
The agent still needs authorized access to the intended meeting population.
The listing requests scope=readable: the same participant, manual-author, project-member, and unfiled company-contributing visibility used by original source reads. Private and restricted-project sources remain inaccessible. The default personal listing is unchanged.
Harness V1 creates or uses its normal attached Workspace output conversation.
New conversations for transcript researchers have contributes_to_knowledge=false.
This prevents feedback into extraction; it is not an access-control setting.
The runtime reuses an already-filed conversation. If unfiled, it files the conversation into the configured agent project; when none is configured, it idempotently provisions an unlisted, non-contributing project owned by the agent and shares it with the configured Foundry owner. A research agent that saves an output gets the same home, including one that is not reading transcripts. This repairs existing unfiled agent conversations too, without changing source permissions. No model-granted project-creation tool is needed. Check the output destination's access separately before using sensitive sources.
Transcript researchers can save outputs only with extraction=none.
Jean Grey uses email and does not call save_output. Other transcript assignments
may still use saved files with explicit grants and extraction=none.
Read coverage and persistence
list_evidence enumerates active meeting metadata through the authorized Workspace
/v1/me/evidence?scope=readable route. It returns pagination and contiguous review progress for
each record's current version. Source access is determined by Workspace, not by
Foundry. Listings use mutable page offsets; rescan from page one periodically.
This first version does not claim snapshot completeness or automatic team coverage.
save_transcript_review records one source page in agent_transcript_review, keyed
by agent, record, source update time, and starting sequence. It verifies the source
is an active meeting transcript, checks each exact quote against human, unredacted
speech, derives page-end status from the cursor, and checks for changes to the reviewed lines
during the read. Empty observations are allowed so coverage does not depend on
finding something interesting. A page limit or redaction is not evidence of absence.
The API uses its existing agent read/run authorization, command idempotency, and transactional outbox. The review table is agent-owned research state, not a replica of the original transcript or a published Intelligence insight. The outbox contains only the agent ID. The API performs structural validation; the harness performs original-source validation. API writes must not be treated as independently verified company facts.
GET /v1/transcript-notes lists saved observations across agents for a half-open meeting-date window of at most 31 days. The same quote saved twice is returned once. A recognition can name the person in subject. A value example can set value and reading. The line number is included so the console can read who spoke it. The notes stay readings of quotes, not published facts.
Progress starts at sequence zero and only extends over contiguous or overlapping
reviewed ranges. Saving a later page cannot hide an unread opening page. Progress
for an old source version does not transfer to a changed source. A zero-line source
read to its end remains an empty source, not a completed substantive analysis.
The progress query caps at 2,000 page reviews and reports limited if exceeded.
list_transcript_reviews reads a half-open meeting-date window of at most 31 days,
three page reviews by default, up to five per request through the harness. Use
pageSize=1 when a response exceeds the output budget. It reopens the originals under the
agent's current authorization and withholds reviews whose reviewed lines changed, became
unavailable, or no longer support the quotations. withheld_unavailable_or_changed
is a coverage warning. Preserve returned pagination even when every item on a page
was withheld. Multiple page reviews are not multiple independent meetings.
Durable continuation
The additional checkpoint fields are mode=transcripts, scan, pending_records,
not_before, briefing_through, and briefing_output_id. The pending queue is
bounded at ten complete record UUIDs. Ordinary memory consolidation cannot erase
these fields or the stored review history.
Transcript checkpoints can resume list_evidence, get_evidence,
get_evidence_utterances, evidence search, list_transcript_reviews,
list_discovery_packets, and get_discovery_packet. They
retain exact source sequences. Checkpoint writes use compare-and-swap versions.
Insight research keeps its existing default and insight-search behavior. A checkpoint
that is not reading transcripts may also resume list_discovery_packets and
get_discovery_packet. An agent that does not have save_transcript_review
cannot keep mode=transcripts. Its next checkpoint save drops that mode, the
scan, and the briefing receipt, and keeps the discovery cursor.
A scan cannot move backward. Restart at page one only with the next scan generation
and complete=true. Pending records prevent completion. A completed transcript
scan can set not_before at most seven days ahead; the runtime skips inference
until then. An unfinished scan that also sets not_before keeps the checkpoint
and drops the deferral. Briefing timing is independent of accepted pages. The prompt sets an initial
30-minute research budget, a weekly completed-period report, and intervening
reports only for material changes. The model records its initial deadline in
research summary and enters phase=synthesize before sending. It may assemble
and send research from earlier evaluations. This is prompt-driven scheduling,
not a deterministic report compiler. A stale checkpoint cannot undo current progress. An unfinished read can defer with a bounded blocked_reason: runtime setup/read failures save a 30-minute not_before while preserving the pending source and cursor. An empty first listing is a blocker, not a briefing. The retry delay survives harness restarts; after recovery the next progress checkpoint clears it.
Discovery and synthesis
The researcher lists relevant in_review and published investigations, including
unreviewed leads and older unresolved findings. There is no required human
usefulness verdict or reporting-period creation filter. It opens
get_discovery_packet, then original supporting and opposing passages and later
updates. Reviewed usefulness helps prioritize work; it is not an evidence gate.
Dismissed, wrong and not-useful claims are excluded. A needs-work card can start
an investigation question, not establish a conclusion.
Discovery reads run as the agent's owner and preserve source access controls.
A card and the original it quotes are one source. Card created_at and
updated_at describe the investigation, not when a business event occurred.
Coverage comes from actual reads, not card counts. Research can jump to relevant
passages without claiming that unread earlier sections have been reviewed.
Briefings distinguish supported findings, tentative connections and open questions. Each point explains business consequence, uncertainty and a useful next action. A promising lead need not meet a witness-count or statistical-significance gate. No source-backed lead is different from proof that nothing happened. No findings may be invented to fill a quota. The prompt avoids empty sections and page-level progress reports.
Existing publish_discovery_insight and file_discovery_contradiction tools retain
their grants and behavior. This workflow does not publish findings automatically.
Migration 0039 updates the catalog, not any stored agent's instructions. Replace
the live prompt only after deploying compatible runtime and schema changes.
A failed discovery read does not stop the evaluation. The agent skips that card
and continues the transcript cursor. The packet id is the idempotency key for
publish_discovery_insight. A later wake that words the title differently
receives the insight already stored for that card. Migration 0040 grants
publish to agents that list discovery cards and do not review transcripts,
including agents created after 0037. The harness offers that tool to the same
set when the catalog contains it. A summary line that says publishing is blocked
is not a finished review.
Delivery state and recovery
Checkpoint phase is collect, investigate or synthesize. summary holds research
conclusions and next questions. discussion holds bounded, unverified context
for a particular record and sequence. Runtime-owned pending_delivery freezes
the outgoing message; deliveries retains the last 64 acceptance receipts.
Manual model checkpoints cannot forge or erase either delivery field or discussion.
Automatic transcript progress does not overwrite research conclusions.
For transcript agents, send_email requires phase=synthesize and a briefing
object: fixed period start/end, reason (initial, scheduled, material_change),
1–50 source/investigation version references, and an explanation for a material
change. Scheduled periods must have ended. Initial and scheduled reports each
have one slot per audience and period; material-change keys also include sorted,
deduplicated source versions. The runtime checks structure and timing; it does
not establish that the source list is complete or the claimed change meaningful.
Those are synthesis judgments that require pilot evaluation.
The runtime persists the frozen payload and then an attempted marker before calling Communications. It saves an acceptance receipt on success. A retry of an already recorded slot returns the receipt. A same-evaluation receipt-save retry uses the known acceptance without calling Communications again. These are Communications acceptance receipts, not proof that the recipient read the email.
Communications currently deduplicates its database command but can invoke the provider again on an HTTP retry. Consequently, a pending attempted transmission without a saved receipt is blocked across evaluations/restarts. Operators must reconcile it against Communications/provider records before clearing or recording the outcome. Do not clear the marker just because the response was lost. A crash between marking the attempt and transmission can therefore hold an unsent report. This favors preventing duplicate messages over automatic recovery from uncertain delivery; it is not an exactly-once provider guarantee. The deterministic request key alone cannot solve this gap.
Old Emailed: summary lines are not reliable receipts and are not imported as
successful deliveries. Before switching an existing emailing agent, stop it,
reconcile its previous sends, and choose the first intended reporting slot. Keep
it stopped until the rollout and pilot are ready. Retain existing scan progress
and page reviews. Older event interpretations are not retroactively revalidated.
Saved-file briefing_through/briefing_output_id semantics remain unchanged and
are not used for email.
Pilot acceptance
Before production rollout, use an authorized set of meetings spanning two weeks and more than one team. Include a commitment followed by completion, a blocker later resolved, a recurring topic without proof of blockage, and a helpful handoff. Compare generated briefings with a human-reviewed evidence set. Check that:
- The briefing distinguishes commitments from completed actions.
- A later resolution defeats an earlier claim that a blocker persists.
- Every conclusion has adequate source context, not only an exact quote.
- Missing or redacted transcripts are recorded as coverage gaps.
- Restarting a harness resumes the correct sequence and does not duplicate a report.
- Repeated meetings, edited sources, and multiple pages do not inflate counts.
The automated tests establish continuation, persistence, citation validation, and access/freshness checks. They do not establish briefing quality on Flow's corpus. Keep the initial pilot under review; do not interpret successful execution as proof of useful organizational conclusions.
Live transcripts and automatic progress
Harness V1 captures the transcript page returned by the source tool. A review saves a SHA-256 digest of the reviewed range, including speech, attribution, and redaction fields. Saving and later report reads compare that range against the original. Appending a later line is allowed; changing the reviewed prefix is not. Legacy reviews without a digest retain conservative timestamp checks. Source-version coverage remains conservative across scans and may reread a changed recording.
Evidence listing automatically checkpoints its pending queue. Each successful page review automatically checkpoints the next source sequence, or selects the next queued meeting at the end. Both tool responses include the new checkpoint version. A crash between review save and checkpoint save may replay the last page; it does not advance past unsaved observations. Source verification failures defer that record without advancing its coverage, and schedule another queued record or page. No model step must be reserved just to preserve an already-saved page. The blocker log includes the actual UTC retry timestamp used by the persisted 30-minute delay.
Reading sections and preserving discussion context
Transcript-mode reads use up to 20 utterances, including older checkpoints or
instructions requesting five. Responses are bounded to 24 KB by dropping only
whole trailing utterances and preserving hasMore; a single oversized utterance
returns an explicit error. The harness records only the delivered section as the
read receipt. Other tools retain their existing response budget.
Each review can include context_summary (at most 2,000 bytes), a rolling,
unverified discussion summary with unresolved questions and sequence references.
The automatic checkpoint carries this summary in discussion into the next evaluation, while
cited observations remain in the review store for briefing assembly. Summaries
are not source evidence and cannot bypass original-quote verification. The runtime
instructions apply this workflow to existing agents without requiring prompt edits.
A saved checkpoint at the step limit is logged as continued progress, not a stall.
Observation meaning checks
For transcript-mode review saves with observations, a separate model call checks whether the proposed event category and summary are supported by the original reviewed section. It uses the agent's research model without tools. Rejected observations are returned with reasons and omitted from the saved review; reading coverage still advances. If any observation is rejected, the proposed context is rebuilt from accepted observations and prior discussion context, with a 2,000-byte cap. This prevents the rejected proposal from entering the new context without erasing all prior context. Prior context is unverified navigation and cannot establish missing antecedents; reopen the original passages. A failed or malformed reviewer response prevents saving rather than silently approving it. This adds one model call per section with observations and is a fallible semantic check, not proof of correctness. Existing saved reviews are not retroactively checked.
Neutral observation and stated question categories retain useful material
without forcing it into a decision or commitment. The checker explicitly
distinguishes capability from undertaking, discovery of an error from its
resolution, and speculation from a confirmed blocker. It remains fallible.
Manual checkpoint writes can change research summary and phase while preserving the last review's separate discussion context. Redundant writes return the existing checkpoint and do not count as progress. Only the harness's review continuation path replaces that context.
Authoritative section bounds
Transcript-mode saves bind their sequence bounds to the most recent successfully
delivered section for the same record in the current evaluation. For example, a
read with since_seq=20 followed by a model save using since_seq=21 is saved with
the original cursor 20. The end comes from the last delivered utterance, never an
invented model endpoint. Empty sections retain the starting cursor. Missing,
wrong-record or malformed receipts fail; original-source and quote verification
still apply. Agents must examine and save a section before reading the next one.
Temporary model failures
The harness waits up to 11 minutes for a model response, beyond the broker’s 10-minute upstream limit. Transport failures, incomplete response bodies, and HTTP 429, 502, 503, or 504 schedule another evaluation after two minutes, preserving the research checkpoint. Other configuration failures retain the existing blocker delay. Retries are sequential and each request has a bounded context; cancellation propagates to the broker’s upstream request. This does not guarantee the external provider stops computation immediately.
Logs record when a step starts waiting for the model and the retry time on failure. Process heartbeats alone do not indicate research progress.
Building and managing agents
The Foundry tools that create, edit, start, stop, and delete agents, the tool that starts an ephemeral coding agent, the tools that handle one Jira issue including a read-only resident investigation, and how a person grants them from the Flow Intelligence Desktop App.
Daily briefs
A morning job writes each person's brief from yesterday's meetings and stores that prose.