InfoOps Report Workflow

Understand the durable research, synthesis, enrichment, and delivery pipeline behind profiles

Every active InfoOps profile runs through a fixed, durable report workflow. The workflow searches the web, optionally expands the topic into child searches, synthesizes one report, enriches it, delivers it to subscribers, and schedules the next run.

Report workflow and Automations are different

This page documents the built-in report pipeline configured through an InfoOps profile. Pro and Elite users can also create Automations that run bounded Agent Y2 work on a schedule or after a profile report completes.

How a run starts

A report run is attached to a profile, not created as an independent workflow object. Y2 queues a run when:

An active custom profile is created.
A paused or cancelled profile becomes active.
An active profile's status or schedule changes.
Its next scheduled execution time arrives.
Recovery logic restarts a failed or stale run.

The start guard skips inactive profiles, prevents a second live run for the same profile, and defers new starts while a retry is already scheduled. Creating an active profile therefore starts an initial report immediately and also schedules its next normal occurrence.

The workflow engine runs for active profiles on every plan. Plan-specific profile, delivery, audio, API, and workspace limits still apply to the surrounding features.

Research and synthesis

1. Search the root topic

Y2 builds a search query from the profile topic and topic-specific hints, then calls Tavily. The research action honors these saved search fields:

Prop

Type

The search action validates freshness using the engine's default topic-aware rules. When it finds stale sources and still has more than three results, it removes stale URLs before synthesis.

The profile's Source Freshness and Link Validation values are stored, but the current research action uses its centralized default freshness configuration rather than those saved switches. Domain and time-range controls above are applied directly.

2. Expand one child layer

When recursion is enabled, an AI step proposes two or three concise, search-ready subtopics. Y2 researches those child topics in parallel and merges successful findings and unique source URLs with the root results. A failed child does not discard successful root or sibling research.

The engine is breadth-first and caps effective recursion at one child layer. It uses a 480-second overall research budget and reserves up to 120 seconds for the child batch before final synthesis.

The current profile editor offers 1-, 2-, and 3-layer labels, but it always saves recursion as enabled. At runtime, an enabled depth of 0 defaults to 1, and values above 1 are capped at 1. The three app choices therefore execute at most one child layer. A public API profile with recursionConfig.enabled: false is the current way to request a true root-only run.

The saved strategy value is accepted by profile schemas, but the current engine always runs the implemented breadth-first path.

3. Synthesize one report

Only the root layer performs synthesis. Y2 combines root and child findings, deduplicates sources, and truncates the combined research document at 35,000 characters before generating one report. The synthesis prompt includes:

The profile topic and up to 2,000 characters of custom instructions.
The saved report format, including supporting instructions, or the default BLUF structure.
Shared OSINT writing guidance for sourced judgments, confidence, alternatives, and evidence gaps; user formatting instructions take precedence over its presentation defaults.
Resolved branding terminology.
A compact summary of up to three previous reports for continuity.
A structured SIGINT contract and the discovered source URLs.

Y2 rejects incomplete synthesis that lacks H2 sections, ends abruptly, or contains no usable signals. A failed quality check stops the workflow before audio or delivery rather than sending a partial report.

Models and provider routing

The app does not expose a report-model selector. The current subtopic and synthesis cascades are fixed in the workflow code:

Stage	Primary	Fallback order
Subtopic identification	`z-ai/glm-5.3-flash`	`google/gemini-3.1-flash-lite`
Final synthesis	`z-ai/glm-5.3-flash`	`minimax/minimax-m2.7`, then `google/gemini-3.1-flash-lite`

On a network failure, a model can be retried once. Parse, timeout, context, or structured-output failures can advance to the next distinct model. If subtopic generation exhausts retryable model attempts, Y2 can use three deterministic child-query templates; final synthesis has no equivalent partial-report fallback.

Public profile schemas currently accept modelConfig.modelId, but the executed subtopic and synthesis model order comes from the fixed cascades above. Temperature and maximum output-token overrides are read; a custom model ID does not replace the cascade's primary model.

Provider requests deny data collection through the configured OpenRouter routing options. See the platform's privacy and data-processing terms for the complete data-handling boundary.

Post-processing and delivery

After synthesis, the durable workflow runs these steps in order:

Generate optional audio

If the profile has Audio Narration enabled, Y2 attempts to create and store the MP3. Audio is non-critical; a failed audio step does not block the report.

Enrich the report

Y2 extracts report events and builds the ontology graph and incident metadata used by downstream product surfaces. Enrichment is required and must finish before delivery.

Deliver to subscribers

Y2 fans the report out according to each active subscription's email, SMS, combined, or webhook configuration. Delivery is critical; a terminal delivery failure fails the run.

Finalize and reschedule

Y2 updates the profile's last-delivery timestamp and hands off the next normal schedule. Recovery logic repairs the schedule when that final handoff fails.

The compact webhook event contains report state, signal and graph counts, audio availability, and links to richer API representations. It does not embed the full report body. See Webhook Delivery for the current contract.

Failure recovery

Y2 records report-generation state on the profile as generating, completed, failed, or canceled. A run receives a 45-minute lease. The recovery watchdog can renew an in-progress lease once for 30 minutes before treating an unresolved run as stale.

Terminal failures can be retried up to three times with delays of 5 minutes, 15 minutes, and 1 hour. When workflow history is available, recovery restarts from the last failed durable step; otherwise it queues a fresh run. After retries are exhausted, Y2 returns to repairing the normal profile schedule instead of retrying indefinitely.

Duplicate starts are skipped while a valid generation lease or future retry exists. If a newly activated profile does not immediately produce a second report, an existing run may already be active or waiting for recovery.

Configure the implemented workflow

Define the research target

In InfoOps → My Profiles, create or edit a profile. Use a specific topic and custom instructions that describe the desired decisions, geography, entities, and output emphasis.

Choose report structure and depth

Set the BLUF sections and review the recursion limitation above. Use the public Profiles API with recursion disabled when a root-only run is required.

Set search boundaries

In Advanced Configuration, choose search depth, time range, result count, and optional include or exclude domains.

Configure delivery and optional outputs

Set the schedule and subscriber method, then enable audio or branding only when the active workspace has those entitlements.

Activate and review the first report

Saving a new active profile queues an immediate run. Review its sources, signals, graph, and delivery history before relying on later scheduled reports.

API boundary

There is no public endpoint for creating arbitrary workflows or directly starting an internal workflow ID. Use the Profiles API to create, update, activate, pause, or cancel the configuration; use the Reports API to read produced reports and derived representations.

The generated Profiles reference is the canonical request schema. Profile writes require profiles:write; report reads require the relevant reports:* scope.