BeliefState

View saved version →

---
name: compare-views-and-follow-changes
description: Compare published BeliefState investment cases and explain how recorded investor views changed over a requested period. Use for opposing theses, investment alternatives, research updates or dated diligence; do not create automatic monitoring or execute trades.
---

# Compare views and follow changes

Answer the comparison or change question the user actually asked; do not run both branches unnecessarily. Reuse adequate cases and history already in the conversation.

## Compare available views

- Identify the requested company, theme, alternatives or two cases. Use `search_beliefs` or a subject brief to discover relevant cases if their IDs are not already available. Open selected cases with `get_belief` when full reasoning is needed.
- Call `compare_beliefs` with distinct returned `belief_id` and `compare_to_belief_id`. If the available schema supports `comparison_focus`, use only the public proposition being compared, never a desired outcome or private portfolio information.
- Explain each investor's thesis, supporting passages, reasons, catalysts, risks, horizon and date. Preserve the returned supports, contradicts, depends_on, unknown or unrelated result and dependency direction. Shared subject matter does not prove agreement, contradiction or independent corroboration.
- Attribute the relationship assessment to the engine. Retain shared-source qualifications, assessment time and the case snapshot cutoff; a stored assessment is not new inference. Do not infer whose research performs better without adequate scoped outcome evidence.

## Explain recorded changes

- Use a concrete requested period or cutoff; clarify an ambiguous period when it changes the question. Use `get_belief_changes` for the ordered journal and a specific returned subject or case selector. Do not replace journal history with search's `changed_since` filter.
- For changes to an investor's stated view, use `domain=author_view`; use `revision_only=true` when only authored revisions are requested. Keep author publication, system observation, condition checks, distribution events and calculated outcomes distinct.
- Explain what changed and what evidence supports the change. Empty or incomplete history does not prove there was no earlier view. Preserve reconstructed, stale, catching-up and resynchronization states.
- For what was known by a historical date, retain `as_of` and recorded availability/observation dates; publication alone does not prove earlier library availability. Use a historical subject brief or case when the user wants a snapshot rather than a journal.
- Continue a requested history window with its returned cursor and unchanged selectors. A continuation cursor is not a next-poll checkpoint. Save a completed polling checkpoint in the customer's AI only after draining that requested window; never invent one. Do not start recurring monitoring, notifications or new research collection from a one-time question.

Adapt detail to the user: a plain-language comparison for an individual investor, a cited change log for an analyst, or exact IDs and continuation fields for a research agent. Keep goals, holdings, quantities, risk preferences and conversation history in the customer's AI. Tool `context` contains only the public research goal, with truthful required model metadata and no private account/portfolio details or credentials. Make the first call serial, then reuse the server's exact `conversation_id` unchanged, including across follow-ups. Use available schemas, preserve citations and unknowns, and relay access/provider errors and recovery guidance without repeated paid retries. These workflows return research, not trading authority.

View saved version →

---
name: find-investment-ideas
description: Find published investment ideas in BeliefState by thesis, investment theme or trade setup, including questions spanning companies without a ticker. Use for evidence-backed idea discovery, not an exhaustive market screener.
---

# Find investment ideas

Use the connected BeliefState tools to help the user explore an investment question. Reuse adequate records already in the conversation before making another metered read.

- Start from the user's public research question: a business trend, sector, catalyst, concern or trade setup. A ticker is optional. Examples include electricity demand, pricing power, refinancing risk or competing investment cases.
- Use `search_beliefs` with `q` for the thesis or topic. Apply only selectors supported by the available tool schema; a natural-language setup is a retrieval question, not a guaranteed structured trade filter. Do not invent a ticker for a non-company subject.
- Return compact candidates with the attributed investor, asset or subject, source date, thesis, matching evidence and material risks. Preserve each returned `belief_id` and citation URL for deeper reading.
- Open selected cases with `get_belief` when needed to explain the idea or answer a follow-up. Do not fetch every candidate merely because it was returned. If the user wants a comparison, use two distinct returned cases with `compare_beliefs`.
- Preserve ranking, indexing and coverage qualifications separately. A top result is not a recommendation, exhaustive market coverage or proof of consensus. No match means no supported match in the available library, not that the investment idea is false.
- Follow a returned search cursor only when more results are useful, with the same query, selectors and historical cutoff. Stop and explain partial/unavailable results rather than silently treating them as complete.
- For a historical question, preserve `as_of` and actual recorded availability/observation dates. An earlier source publication date alone does not prove the library or customer could access that view then.

Use plain language for a beginner and retain IDs, dates and evidence for an analyst or research agent. Distinguish the source's stated view from BeliefState's engine analysis and your interpretation. Shared topics or authors do not establish independent support. Missing dates, conviction, conditions or outcomes stay unknown; do not infer trades, investing skill or returns.

Keep goals, holdings, position sizes, risk preferences and conversation history in the customer's AI. Send only bounded public research selectors and a short public research goal as tool `context`, never private portfolio/account details, credentials or source bodies. Supply required model metadata truthfully. Make the first tool call serial, then reuse the server's exact `conversation_id` unchanged, including across follow-up requests. Use the available schemas rather than assuming newer fields or unpublished tools. Research can consume allowance or prepaid credit; on access/provider failures, relay the returned error and recovery guidance without inventing evidence or repeated paid retries.

View saved version →

---
name: research-a-company-or-etf
description: Explain available BeliefState research about a company or ETF, from a beginner's overview to an analyst brief with investor views, catalysts, risks and cited cases. Use for company or fund research, not bulk financial-statement feeds or portfolio management.
---

# Research a company or ETF

Help the user understand the available research at the level they requested. Reuse adequate conversation records before making another metered read.

- Resolve the requested company, ETF or subject before retrieving research. Ask which investment when none was given. Use `search_companies` to resolve an ambiguous company name; use returned identifiers and clarify multiple listings rather than guessing. Use `search_entities` when a released non-company subject is the intended target.
- Start ordinary company or ETF research with `get_brief`, using the default or `detail=overview` supported by the connected schema. Do not assume `detail=current` or brief cursors are published on every client. Do not request a full export when an overview answers the question.
- For an ETF ticker, try its brief rather than treating absence from a direct-company coverage directory as proof that ETF research is unsupported. Explain the date of fund holdings, available constituent-company research, omitted holdings and coverage limits. Do not imply a complete thesis about every fund or its constituents.
- Lead with what the available attributed views say, why those investors hold them, material catalysts and risks, and the source dates. Separate investor views, issuer/market context, engine assessments and your own synthesis. Date prices and preserve stale or missing context.
- Open requested complete cases with `get_belief`. Use `get_belief_risks` or `get_belief_catalysts` for a requested object-level investigation, with exactly one supported subject scope. Preserve citations and unknown conditions; a combined summary is not multiple independent records.
- Keep the answer useful for learning about a business, preparing an analyst brief, examining a sector exposure or building an evidence packet. Let the customer's AI apply personal goals and preferences. State when the library cannot support a requested conclusion instead of supplementing it with invented research.
- Refresh market data only when the user requests a refresh and the available tool supports the subject. Historical questions retain their `as_of` cutoff and never become a current-data refresh. For what was known by a past date, use recorded availability and observation dates as well as publication; later discovery cannot be backdated into earlier knowledge.

Keep goals, holdings, position sizes, risk preferences and conversation history in the customer's AI. Send only bounded public research selectors and a short public research goal as tool `context`, never private portfolio/account details, credentials or source bodies. Supply required model metadata truthfully. Make the first call serial, then reuse the server's exact `conversation_id` unchanged, including across follow-up requests. Preserve returned IDs, citations, coverage, omissions, dates and nulls. Use connected schemas and returned continuations rather than unpublished tools. Research can consume allowance or prepaid credit; explain the returned access/provider error and recovery guidance without fabricated results or repeated paid retries.