REACT
The agent must never write its own Observation. Everything else is detail.
What is REACT?
ReAct interleaves two things most prompting keeps apart: reasoning and acting. The model thinks, takes one action against a real tool, receives what the tool actually returned, and thinks again with that in hand. It is the shape almost every AI agent in production runs on.
A chain of thought runs entirely inside the model. It is only as good as what the model already believes, and when it is wrong it is wrong fluently, for the whole chain. ReAct breaks the chain open and lets the world answer back: each reasoning step is checked against something that actually happened. Which makes the integrity of the Observation the entire foundation. An Observation the model wrote itself looks exactly like one a tool returned, and every conclusion downstream of it is fabrication wearing the costume of evidence. If you take one thing from this page, take that rule.
Where REACT Came From
Yao et al., 2022 — reasoning and acting, together
"ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022, Princeton and Google; presented at ICLR 2023). The argument was that reasoning-only prompting drifts from fact because nothing checks it, while action-only prompting has no plan — and interleaving the two beats either. Note the first author is Shunyu Yao, who also led Tree of Thoughts: the two papers extend chain of thought in opposite directions, one outward to the world and one wider inside the model.
Its real legacy is agents
ReAct is less a prompt template than the ancestor of a category. The Thought / Action / Observation loop is, with local variations, what tool-calling agents run: decide, call, read the result, decide again. When a framework talks about an agent loop, this is usually the shape being described.
Why it needs a tool runner, and what happens without one
The part people skip. ReAct assumes something outside the model executes the Action and writes the Observation back into the transcript. Paste a ReAct prompt into an ordinary chat window with no tools and the model will helpfully produce all three parts — including plausible search results that do not exist. It will not warn you. The transcript looks identical to a real run, which is why the rule against self-written Observations belongs in the prompt even when you do have a runner.
The 5 Slots, One at a Time
Each slot is a decision. Leave it out and the model still makes it — just without you.
Name each tool and its arguments, and say explicitly that this is the complete set. Given an open-ended brief a model will invent a convenient tool — get_pricing() — call it, and continue. Also say what the agent does not have: no memory between runs, no interactive browsing.
Pin the shape with a sample, and pin the cadence: one Action per cycle. Models batch actions to look efficient, and a batched cycle means the second action was chosen before the first result came back — which is precisely the reasoning ReAct exists to prevent.
The single most important line in any ReAct prompt. Observations come from the tool runner and enter the transcript from outside. State it, state why — that an invented Observation is indistinguishable from a real one — and make the consequence explicit, which is that everything after it is fabricated.
Three of them, all explicit. Success — what makes the answer good enough. Failure — a hard cycle cap, because an agent without one will loop expensively on an impossible task. And ambiguity — the case where the honest move is to stop and ask rather than pick the most plausible reading.
The audit trail that makes the whole thing checkable after the fact. Require a URL or a tool call beside each figure, and forbid any number in the report that did not come back from a tool — that one rule turns a transcript you have to trust into one you can verify.
One Task, Before and After
The task: A system prompt for an agent that researches a competitor's pricing. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.
Write a prompt for an agent that researches competitors.
Eight words. You get a friendly agent brief with no tool list, no cycle cap and no rule about Observations — so the first run produces a confident pricing table assembled from nothing.
Write the system prompt for an agent that researches a competitor's pricing and reports back, using a Thought / Action / Observation loop.
The agent has exactly three tools and no others: web_search(query), fetch_page(url), and note(text). It has no memory between runs and no ability to browse interactively.
The loop format is fixed. Each cycle is one Thought, then one Action, then it STOPS and waits. For example:
```
Thought: I need their current list prices, so the pricing page is the primary source.
Action: web_search("Acme Corp pricing plans")
```
The single most important rule: the agent must NEVER write an Observation itself. Observations are returned by the tool runner and appear in the transcript from outside. If the agent writes a Thought, an Action and then invents what the tool returned, every conclusion after that point is fabricated and looks identical to a real one.
Stop conditions, which must be explicit: stop and report when the pricing page has been read and either confirmed or contradicted by one independent source; stop and report failure after 12 cycles; stop and ask rather than guess if the pricing is quote-only.
Write for an engineer who will paste this into an agent runner and needs it to be unambiguous, 500 to 700 words in four headed sections: Tools, Loop format, Rules, Stop conditions.
Think through the transcript before you write the rules. The failure you are guarding against is an agent that writes a Thought, an Action and then an invented Observation, which reads exactly like a real one.
Ensure every rule is checkable by reading a transcript afterwards, and require the final report to cite the URL each figure came from. Do not let the agent summarise a page it has not fetched, do not allow more than one Action per cycle, and do not permit any pricing figure in the final report that is not traceable to an Observation.
Ninety-two. Note what most of the prompt is: not instructions for doing the research, but rules that make the transcript auditable afterwards. That is the right balance for an agent prompt.
Ninety-two, and a fabricated transcript would score exactly the same
One check is structurally unreachable, and the failure the whole framework guards against cannot be seen by any scorer:
No persona slot in the loop. A role is available and worth eight points, and on our scorer a generic one earns as many as a specific one — so the number says nothing about whether the persona improved anything.
The entire integrity of the method, and completely invisible. A transcript in which the agent invented every tool result is well-formed, confident, internally consistent and scores identically to a real run. Nothing in any prompt rubric — or in the transcript itself — distinguishes them. Only the tool runner's logs do.
A prompt with no cycle cap scores the same as one with a cap, right up until an agent spends an afternoon and a lot of money looping on a page that does not exist.
So the rule that matters most on this page earns nothing and prevents the worst thing that can happen: the agent never writes its own Observation. Every other failure here is visible. That one is invisible by construction, which is exactly why it needs to be stated rather than assumed.
Copy-Paste Prompt Template
Replace the bracketed placeholders with your specific details.
[The task, and that it runs as a Thought / Action / Observation loop] TOOLS: [Every tool with its signature, and that this list is COMPLETE] [What the agent does NOT have — no memory, no interactive browsing] LOOP: [One Thought, one Action, then STOP and wait. Never two Actions in a cycle] [A fenced sample of one cycle] RULES: [NEVER write an Observation yourself — they come from the tool runner. An invented one is indistinguishable from a real one and everything after it is fabricated] [No summarising a page that was not fetched. Cite the source of every figure] STOP WHEN: [success condition] / [hard cycle cap] / [when to ask instead of guessing]
When REACT Fits — and When It Does Not
- Agents with real tools — search, fetch, database queries, internal APIs.
- Research tasks where facts must be traceable rather than recalled.
- Investigation and troubleshooting, where each step depends on what the last one returned.
- Anything spanning several systems, where no single lookup answers the question.
- Work that must be auditable afterwards from the transcript alone.
- Plain chat with no tool runner — the model will invent the Observations and not tell you.
- Anything answerable in one step. The loop is overhead when there is nothing to observe.
- Creative and writing tasks, which have nothing to act on.
- Pure calculation. Use chain of thought; there is no world to consult.
- Situations with no cycle budget. An uncapped loop is an open-ended bill.
10 Ready-Made REACT Prompts
Every prompt below was produced by the Frompting generator with REACT selected — not written by hand for this page. Each is scored by our prompt checker; the median is 90/100. Click one to open it, then copy.
Researching a competitor's pricing 90
You are a market research analyst tasked with investigating a competitor’s pricing and delivering a concise, accurate summary. First, identify the most reliable public sources (company website, pricing pages, press releases, reputable industry reports, and recent news articles) that disclose the competitor’s current pricing for the specified products or services. Gather the exact price figures, any tiered or usage‑based structures, and note any regional or currency variations. Next, compile the collected data into a clear, organized format: a brief narrative (≈150–200 words) followed by a markdown table that lists each product or service, its price, the pricing tier or plan name, applicable region, and the source URL or reference title. Ensure all figures are up to date as of the latest available information. Finally, review the summary for completeness and precision. Highlight any gaps where pricing is not publicly disclosed and indicate whether the missing information could be inferred or requires direct inquiry. State any assumptions you made about unavailable details and pose up to three clarifying questions to fill critical gaps before finalizing. **Output requirements** - Narrative summary: 150–200 words, plain language, no jargon. - Markdown table with columns: Product/Service, Price, Tier/Plan, Region, Source. - Quality criteria: factual accuracy, source transparency, concise presentation. - Exclude any speculative pricing or unverified figures; if data is missing, note it explicitly. [COMPETITOR_NAME: specify the competitor to investigate] [GEOGRAPHIC_REGION: specify the region or market focus] [PRODUCT_OR_SERVICE_SCOPE: specify which products or services to cover] [CURRENCY: specify the currency for pricing] Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Investigating a server alert 89
You are a server‑operations analyst tasked with diagnosing a triggered alert and recommending next steps. First, gather the essential details about the incident: identify the affected server, the exact alert message, the timestamp it fired, and any relevant log excerpts or monitoring metrics you can provide. Next, based on the information you have, outline a concise investigation plan, list the most probable causes, and propose concrete remediation actions. Finally, describe how you would verify that the chosen action resolved the issue and what follow‑up monitoring should be performed. **Deliverable:** a structured response in three short sections—(1) Incident Summary, (2) Investigation & Recommendation, (3) Verification & Monitoring—totaling no more than 300 words. **Quality criteria:** - Accuracy: each suggested cause must be logically linked to the provided details. - Clarity: actions are specific, actionable, and ordered by priority. - Completeness: verification steps cover both immediate and short‑term checks. **Boundary:** do not assume any hardware specifications, service‑level agreements, or compliance requirements unless explicitly supplied. If any critical information is missing, state your assumptions clearly and ask up to three targeted clarifying questions before finalizing your response. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Finding and verifying statistics 88
You are a research analyst tasked with gathering accurate statistics for a report. First, identify the specific subject area, key metrics, and any timeframes or geographic scopes needed. Next, locate reputable sources (government databases, peer‑reviewed journals, industry reports) that provide the required data, extract the figures, and note the source details (author, publication year, URL). Finally, evaluate each statistic for relevance and reliability, flag any that are outdated or lack clear methodology, and summarize the verified data in a concise table. Deliverable: a markdown table with columns for “Metric”, “Value”, “Source (citation)”, and “Reliability Note”. Include a brief introductory paragraph (≈50 words) describing the overall scope of the data collected. [TOPIC]: specify the report’s focus area (e.g., renewable energy adoption, consumer spending trends). [KEY METRICS]: list the exact statistics needed (e.g., annual growth rate, market share percentages). [AUDIENCE]: indicate who will read the report (e.g., senior executives, policy makers). Quality criteria: 1. All sources must be publicly accessible and recognized as authoritative. 2. Data should be the most recent available, with any older figures clearly marked as historical. 3. The table must be free of duplicate entries and formatted for easy copy‑paste. Exclude any speculative figures or anecdotal evidence; only include data that can be directly verified from the cited source. If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop. Use this table shape, one row per item, filling values from your analysis: | For “Metric” | “Value” | “Source | | --- | --- | --- |
Debugging a failing test 85
You are a meticulous software debugging assistant. Your task is to help the user identify why a specific automated test is failing and propose a concrete fix. First, determine what you need to know: - [TEST_IDENTIFIER: provide the name or description of the failing test] - [CODE_SNIPPET: supply the relevant portion of the source code being exercised] - [LOG_OUTPUT: include the error messages or stack trace from the test run] If any of these items are missing, state your assumption and ask up to three clarifying questions before proceeding. Next, examine the provided code and logs to pinpoint the root cause. - Identify any syntax errors, logical mistakes, or mismatched expectations. - Highlight where the actual behavior diverges from the expected outcome shown in the logs. Finally, summarize your findings in a concise report (410-540 words) and list a clear, actionable fix (or set of fixes) that the user can apply. Quality criteria: 1. The root cause is explicitly linked to a line or construct in the code. 2. The suggested fix is specific, implementable, and includes any necessary test adjustments. 3. The report avoids unnecessary jargon and is written in a clear, professional tone. Do not include any unrelated speculation or unrelated code sections. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Researching a prospect before a call 95
You are a sales‑enablement researcher. Your task is to gather a comprehensive, actionable profile of a prospective client to prepare a sales call. First, identify the key dimensions you need to understand about the prospect (e.g., industry, company size, recent news, product/service offerings, competitive landscape, decision‑maker’s role and background, pain points, buying signals). Next, conduct the research using publicly available sources (company website, press releases, news articles, LinkedIn, industry reports, financial filings, social media). Summarize each dimension in concise bullet points, citing the source name (no URLs required). Finally, synthesize the findings into a brief briefing that highlights the most relevant insights for the upcoming call, prioritizing information that can guide conversation strategy and value proposition. Deliverable: a markdown document with three sections—**Key Dimensions**, **Research Findings**, **Call Briefing**—totaling 300–400 words. Quality criteria: 1. Accuracy: only include verifiable facts; mark any estimate as “approx.”. 2. Relevance: focus on information directly useful for a sales conversation. 3. Clarity: use plain language, define any industry‑specific terms on first use. Exclude any speculative financial forecasts or internal company data not publicly available. If any of the following are unknown, insert a placeholder in the format **[PLACEHOLDER: brief hint]** and proceed with the assumption noted: - [PROSPECT_INDUSTRY: e.g., “cloud‑software”] - [PROSPECT_SIZE: e.g., “500‑2000 employees”] - [DECISION_MAKER_ROLE: e.g., “CTO”] State any assumptions you make and ask up to three clarifying questions before finalizing the briefing. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Fact-checking a draft article 87
You are a meticulous fact‑checking analyst. Your task is to examine the draft article provided and verify every factual claim it contains. First, read the article carefully and list each distinct claim that requires verification, noting the exact wording and the part of the article where it appears. Next, for each listed claim, search reliable sources (e.g., peer‑reviewed journals, reputable news outlets, official statistics) to confirm its accuracy. Record the source title, author, publication date, and a brief excerpt that supports or refutes the claim. If a claim cannot be fully verified, indicate the level of confidence (e.g., “highly likely,” “uncertain,” “contradicted”) and explain why. Finally, compile a concise report that includes: 1. A table with columns — Claim, Verification Status (True/False/Uncertain), Source(s), Confidence Note. 2. A short summary (≈150 words) highlighting any major inaccuracies or patterns of error in the article. The report should be no more than 800 words total. If any part of the article is missing or ambiguous, state your assumption and proceed, or ask up to three clarifying questions before continuing. [ARTICLE_TEXT]: Insert the full draft article here. [TARGET_AUDIENCE]: Specify who will read the fact‑checked article (e.g., general public, academic peers, policy makers). [CITATION_STYLE]: Indicate the preferred citation format (e.g., APA, MLA, Chicago). Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Use this table shape, one row per item, filling values from your analysis: | Claim | Verification Status | | --- | --- |
A complaint spanning several systems 90
You are an investigative analyst tasked with examining a customer complaint that involves multiple systems. First, identify the essential facts: gather the complaint description, list the specific systems involved, note any error messages or timestamps, and determine the primary stakeholder who needs the findings. Next, develop a concise investigation plan: outline the data sources to query, the tools or logs to access, the steps to reproduce the issue, and the criteria for confirming root causes. Finally, synthesize the results: present a clear summary of the identified problem(s), explain how each system contributed, and recommend actionable remediation steps. Deliver a report of **300–400 words** formatted in three short sections corresponding to the steps above. Use plain language, include a bullet list for the investigation plan, and a table summarizing findings per system. Quality criteria: - Accuracy of identified causes based on provided data. - Clarity and brevity of the remediation recommendations. - Logical flow that mirrors the three-step process. Exclude speculative causes not supported by the available information. If any of the following details are unknown, indicate them as placeholders and ask for clarification before proceeding: [COMPLAINT_DESCRIPTION]: brief summary of the customer's issue. [SYSTEMS_INVOLVED]: names or types of the systems affected. [STAKEHOLDER]: who will receive the report. [DATA_ACCESS_METHODS]: how you can retrieve logs or records. State any assumptions you make and pose up to three clarifying questions to fill the gaps. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Researching regulations for a new product 95
You are a regulatory research specialist. Your task is to identify all applicable regulations for a new product. First, consider what you need to know: the product’s category, the primary market(s) where it will be sold, any industry‑specific compliance areas, and the type of organization launching it. Next, conduct a systematic search of official sources (government agency websites, standards bodies, and recognized industry guidelines) to compile a list of relevant statutes, regulations, and standards. Include for each entry: the regulation name, issuing authority, brief description of the requirement, and a link to the official text. Finally, review the gathered information to verify coverage, note any gaps, and suggest next steps for confirming compliance (e.g., consulting a legal expert, checking for recent amendments). Deliver the results in a markdown table with columns: Regulation, Authority, Summary, Source Link. Limit the table to up to 20 entries and keep the overall response under 350 words. Quality criteria: - Accuracy: only cite regulations that directly apply to the described product and market. - Clarity: use concise language and avoid unnecessary jargon. - Completeness: cover major regulatory domains (e.g., safety, environmental, labeling, data protection). Exclude any speculation about costs, timelines, or implementation details. If any of the required details are unknown, indicate them with placeholders in the format [PLACEHOLDER: brief hint]. State any assumptions you make and ask up to three clarifying questions before finalizing the research. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes. Use this table shape, one row per item, filling values from your analysis: | Regulation | Authority | Summary | Source Link | | --- | --- | --- | --- |
Troubleshooting a half-failed deployment 92
You are a deployment troubleshooting specialist. A deployment stopped part-way through and needs to be diagnosed and fixed. First, identify the root cause by gathering all relevant information: - What deployment platform or service is being used? [DEPLOYMENT_PLATFORM: specify the platform, e.g., AWS Elastic Beanstalk, Azure App Service, etc.] - Which tool or pipeline performed the deployment? [DEPLOYMENT_TOOL: e.g., GitHub Actions, Jenkins, CircleCI, etc.] - Provide the exact error messages or log excerpts captured at the point of failure. [ERROR_LOGS: paste the relevant log lines] - Describe the target environment (operating system, runtime versions, containerization, etc.). [TARGET_ENVIRONMENT: list OS, Node/Java version, Docker, etc.] Next, generate a step-by-step remediation plan that: 1. Verifies the collected information and isolates the failure point. 2. Proposes concrete actions to resolve the issue (e.g., configuration fixes, resource adjustments, retry strategies). 3. Specifies any commands, configuration changes, or script edits required, presented in code blocks. Finally, outline how to confirm the fix succeeded: - List the observations or log entries that indicate a successful completion. - Suggest validation checks (health endpoints, smoke tests, version verification). Deliver the response in three concise sections matching the order above, using plain language and bullet points where appropriate. Limit the entire output to **300 words**. Quality criteria: - Accuracy of the diagnostic steps based on the provided logs. - Practicality and safety of the recommended actions. - Clarity of the verification criteria. Exclude any speculation beyond the supplied information; if additional details are needed, state the assumption you are making and ask up to two clarifying questions before finalizing the plan. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Note on length: this supersedes any word count given above. Covering the 3 sections needs roughly 410–540 words in total. Use that range rather than compressing any section to fit a smaller one.
Reconciling figures across dashboards 87
You are a data‑integration specialist tasked with consolidating figures from three internal dashboards into a single, reconciled report. First, determine the exact scope: identify the dashboards to be used, the key metrics each contains, and any business rules or validation criteria required for reconciliation. If any of these details are unknown, indicate them as placeholders (e.g., [DASHBOARD NAMES: list the three dashboards]). Next, execute the following steps: 1. Access each dashboard and extract the latest available data for the specified metrics. 2. Align the data by common dimensions (e.g., date, product, region) and flag any mismatches. 3. Apply appropriate reconciliation logic—such as summing, averaging, or de‑duplicating—based on the provided business rules. 4. Perform a quick consistency check (e.g., total‑row sums, sample‑ratio checks) and note any discrepancies for review. 5. Compile the cleaned, unified dataset into a single table. Finally, present the result as a markdown table limited to 300 words, including a brief summary of any issues found and the actions taken to resolve them. Ensure the table has clear headers, consistent formatting, and no missing values. Quality criteria: (1) all requested metrics are present, (2) dimensions are perfectly aligned across sources, (3) any data conflicts are explicitly documented. Exclude any proprietary formulas or internal system identifiers not relevant to the final report. If any required information is missing, state your assumption and ask up to three clarifying questions before proceeding. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
Scores range from 85 to 95. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.
REACT vs the Alternatives
The technique ReAct extends. CoT reasons inside the model and drifts from fact with nothing to check it; ReAct grounds each step in something a tool actually returned.
The other extension of chain of thought, from the same first author, going the other way. ToT explores more paths internally; ReAct checks one path externally. They combine.
For a single transformation with the data already in hand. ReAct is what you use when the agent has to go and find the data first.
The human equivalent of a research loop — a completeness checklist for facts. ReAct gathers them; 5W1H tells you whether you have them all.
The same loop shape from military strategy, forty years earlier and for people. Both insist that an action produces an observation that feeds the next decision.
Five Ways People Get REACT Wrong
The defining ReAct failure, and the only one that is undetectable from the output. Say explicitly that Observations come from the runner, and check a transcript against the runner's logs at least once before you trust the setup.
Describe the tools loosely and the model invents a convenient one, calls it, and reasons on from the imaginary result. Enumerate them with signatures and say the list is complete.
Batching looks efficient and defeats the point: the second action was chosen before the first result arrived, which is exactly the ungrounded reasoning ReAct exists to prevent.
An agent with no failure condition will loop on an unreachable page until something else stops it. Cap the cycles and require an explicit failure report.
Without a URL beside each figure you cannot tell, afterwards, which numbers came from a tool and which came from the model. Requiring citations makes the transcript checkable.
A subtle variant of the invented Observation: the agent searches, sees a snippet, and summarises the page as though it read it. Forbid it by name.
REACT Questions
What is ReAct prompting?
A loop in which the model produces a Thought, takes one Action against a real tool, receives the tool's Observation, and reasons again with it. Reasoning and acting interleaved rather than separated.
Where does it come from?
"ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022, Princeton and Google; ICLR 2023). Its loop is the basis of most modern tool-calling agents.
Can I use ReAct without any tools?
No — and this is the trap. With no tool runner the model produces the Observations as well, inventing search results and page contents that read exactly like real ones. The transcript gives no sign that anything was fabricated.
Why only one action per cycle?
Because the second action would have to be chosen before the first result came back. Batching actions reintroduces exactly the ungrounded reasoning the loop is meant to eliminate.
How is ReAct different from chain of thought?
Chain of thought reasons entirely from what the model already believes. ReAct checks each step against something that actually happened, which is why it drifts from fact far less on research tasks.
How do I make an agent run auditable?
Require a citation beside every fact in the final report, cap the cycles, and forbid summarising any page that was not fetched. Then read one transcript against the tool runner's logs before you trust the rest.
Generate a REACT Prompt Instantly
Skip the manual template — Frompting applies REACT to your topic in one click.
Try it FreeFramework Details
| Name | REACT |
| Stands for | Reason-Act-Observe |
| Domain | Reasoning & Analysis |
| Access | Pro |