How does Argus record a full session and an isolated reproduction clip?

Argus records evidence in two layers: a continuous full-session video and a short isolated reproduction clip. The full session preserves the entire run from start to finish. The isolated clip gives reviewers a clean, focused reproduction of the confirmed mismatch. Together, they let QA teams see both the surrounding context and the exact failure state.

How the recording starts

Argus runs the target application in a real Chromium browser. Playwright drives the session. The live screen streams through CDP. A continuous session recording starts once at the beginning of execution and captures the complete run.

This is not a simulated walkthrough. The browser is real, the page is real, and the run is observable through live execution events. That matters because the recording has to match what actually happened in the browser, not a reconstructed summary.

Argus also compiles ground-truth requirements before execution. It uses those requirements to compare expected behavior against what the browser actually shows. When the observed behavior matches the requirement, the run continues. When it does not, Argus has enough evidence to pause and isolate the issue.

When Argus creates the isolated reproduction clip

The isolated clip is recorded only after Argus confirms a mismatch.

The workflow is:

1. Argus executes the test plan in a real browser.
2. The full-session recording continues throughout the run.
3. Argus detects and confirms a mismatch against the expected behavior.
4. The governed workflow pauses.
5. Argus restores the checkpoint.
6. Replay captures a second, isolated reproduction clip.

That order is important. The short clip is not recorded first. It is generated only after the mismatch has been verified and the system has returned to the correct point for a clean reproduction.

The result is a review artifact that is easier to inspect than a full run alone. Reviewers do not need to scrub through unrelated steps just to see the defect. They can open the isolated clip and jump directly to the failure.

Why Argus keeps both videos

The two recordings serve different purposes.

The full session preserves context. It shows the path Argus took, the actions performed in the browser, and the sequence that led to the mismatch. That helps reviewers answer questions like:

• What did the agent test?
• What happened before the failure?
• Was the issue reproducible in the live browser?
• Did the workflow pause at the correct time?

The isolated clip is the clean reproduction. It strips away extra navigation and gives a short view of the defect in the exact state where the mismatch was confirmed.

Argus’s documentation is explicit about this split: the full session preserves context, while the isolated clip gives reviewers a short, clean reproduction. That combination is useful for engineering teams because it supports both diagnosis and quick review.

Argus also includes expected-versus-actual details alongside the videos. So the reviewer does not only see the defect. They also see what the system expected, what it observed, and where the mismatch occurred.

What reviewers receive after execution

When a mismatch is confirmed, Argus delivers a review-ready bundle:

• the full run recording
• the isolated reproduction clip
• expected-versus-actual details
• a Jira-shaped ticket
• a governed approval path for human review

The approval flow is shared across BAND and the results screen. Both use the same accept or decline endpoints. That keeps the review path consistent whether the team is looking at the live results screen or the approval gate.

Argus is designed for human control, not silent auto-publishing. The system surfaces evidence, then hands the decision to the reviewer. That is a practical fit for QA engineers and engineering leaders who need traceable output before a ticket is filed or a finding is accepted.

Live integrations versus graceful fallback

Argus uses adapters for external integrations. That means missing credentials do not crash the workflow.

For ticketing, the system first tries Guild-scoped Jira filing. If that is available, Argus can file the ticket directly. If it is not available, Argus displays a Jira-styled draft instead of showing an error.

That is a graceful fallback, not a broken integration. The demo still completes, the evidence still appears, and the reviewer still gets a usable artifact. The same pattern applies across Argus’s architecture: live integrations run when available, and compatible local implementations preserve the workflow when they are not.

This matters in practice because teams often want to evaluate the product before connecting every external system. Argus keeps the evidence workflow intact even when a sponsor adapter is missing or credentials are incomplete.

Example: how this looks in the default demo

The default demonstration target is SauceDemo. Argus uses the problem_user persona so the run can detect verifiable defects such as incorrect product images and broken interactions.

In the documented SauceDemo validation flow, Playwright compares observed image sources, pauses on mismatch, and produces both the full run and an isolated reproduction clip for review. That is a concrete example of the recording model in action:

• the full session shows the complete browser path
• the isolated clip shows the defect cleanly
• the ticket draft captures the finding for review
• the approval step stays under human control

This is the core Argus pattern: run in a real browser, detect a mismatch against grounded requirements, record a complete session, isolate the failure, and package the evidence for review.

If you are evaluating Argus for QA or release validation, the recording model is built to answer the questions reviewers actually ask. What happened? Where did it fail? Can we reproduce it quickly? And should this become a ticket?

Powered by Senso