What Flock reviews
Flock runs AI personas through product experiences and returns observations, evidence, and ratings. The personas are synthetic perspectives. They can help you find a problem to investigate; they are not a sample of real customers.
Three questions make a review useful: what did we ask it to do, what did it actually observe, and what does the evidence support?
Workspace, review, and run
A workspace is the context for your team’s access, reviews, and integrations. An MCP connection is authorized for a selected workspace. Signing in to the same Flock account does not make every workspace available through that connection.
A review brings together the results for a configured test. A review can contain several runs, each associated with a persona. You may also see batch in API fields or older routes for this grouping. Review-level summaries and individual run details cover different scopes; do not count the same findings twice.
A persona supplies characteristics and a perspective for the model’s judgment. Selecting several personas broadens the perspectives in a synthetic review. It does not establish statistical representativeness or predict how many customers will have the same reaction.
Target, goal, and flow
The target is the application URL to review. A page review inspects a captured page. A multi-step flow follows an objective through the allowed interactions and bounds.
The goal states the task you want the persona to attempt, such as creating a workspace and inviting a teammate. A success signal supplies a concrete condition to check, such as the appearance of confirmation text. Choose a condition that reflects the intended outcome; vague goals make the result harder to interpret.
The final result still needs inspection. Goal achieved can be yes, no, or unknown. A run’s completed status describes execution, not proof that its goal was achieved. Stopped or failed runs can leave useful evidence and incomplete coverage at the same time.
Scores, findings, and evidence
Scores are the model’s ratings of the persona’s experience: clarity, trust, engagement, willingness to recommend, frustration, and happiness. The percentage display is a scale conversion. It is not a measured customer response rate. Read how review scores work for the scoring instructions, aggregation, and limits.
Findings describe specific observations. Severity expresses priority; Verified and Directional describe different levels of support. Evidence is the captured material you can inspect. Read findings and evidence before treating a finding, confidence number, or repair suggestion as established fact.
Abandonment risk and would abandon are separate synthetic judgments. They do not measure actual customer churn. The score guide explains how the dashboard summarizes them.
Saved sign-in and connected tools
Saved sign-in lets Flock use an authenticated browser profile when reviewing a target that requires login. Complete human login and MFA in Flock’s browser handoff. A profile can expire or require reconnection; selecting it is not a guarantee that the next review will be authenticated successfully.
Your MCP connection authorizes an AI client to call Flock. That OAuth login is separate from the saved sign-in used to enter your application. Neither requires you to paste passwords, tokens, cookies, or browser storage into chat.
Read access lets the agent inspect authorized information and prepare a review. Test access adds review actions, subject to workspace permission. An estimate or a recommendation does not launch a run. The agent should show the proposed test and estimate before an approved launch. See MCP setup for exact scopes and steps.
Local clients and hosted reviews
A local coding client can connect to Flock’s hosted MCP service. The localhost OAuth callback belongs to the client’s sign-in flow. It does not mean Flock runs on your laptop.
The application being reviewed is a third address. Flock’s hosted browser needs a reachable target that meets workspace URL policy. A localhost development server on your machine is not made reachable by connecting MCP. Use an appropriate preview or staging deployment. The connection and environment guide explains the distinction and remote-development limits.
The CLI is a separate way to run the Flock runtime from a configured checkout. It needs its own runtime access and dependencies. It is not required to connect a coding client to hosted MCP. See the CLI guide for that setup boundary.
Baselines, comparisons, and repair prompts
A baseline is the reference used for a later comparison. For GitHub reviews, the first successful target review on a PR can establish that PR’s baseline. A baseline provides context for later changes; it is not a certification that the starting experience is correct.
A repair prompt packages a finding’s context and guidance for a coding agent. Its availability depends on the result and supporting artifacts. The agent still needs to inspect the evidence, respect uncertainty, and test its change. “Not observed in the latest comparison” is limited to that comparison’s coverage.
The GitHub App guide explains preview readiness, repository settings, baselines, and the Preview Gate.
Public answers and private results
Flock’s public docs explain the product, its integrations, pricing, and policies. A connected MCP agent can search that published information and provide source links. It retrieves workspace data and review evidence through separate authorized tools.
A public definition cannot tell you whether your particular review succeeded. For that, the agent needs the actual result, its coverage, and its evidence. When a summary, image, or page is unavailable, the answer should say so rather than fill in the gap.