Start here / one concrete request
“Which background-removal service should Pine Studio use for its commercial web editor?”
Pine Studio is fictional. Its editor needs transparent PNGs, must serve desktop and mobile browsers, and cannot use a license that forbids commercial use. The team knows its needs but does not yet know every constraint that could change the choice.
A useful result would explain the choice, cite the conditions that matter, and name what remains untested or unsettled. This scenario illustrates the research flow; it is not a real vendor recommendation or a completed product trial.
From request to result
What happens next
-
Bring the question
Pine’s assistant asks Seeker which background-removal service fits its commercial editor. It includes what Pine already knows: the editor needs transparent images and must serve desktop and mobile customers. Pine does not have to know every pitfall or choose a search service. Seeker takes responsibility for finding what else matters.
What moves forwardThe question and known constraints reach the planner.
How this step works
The assistant calls Seeker through MCP, its tool connection. The input is a plain-language problem plus optional context, not a required answer outline or search-depth setting. Seeker keeps the original request for later review. If missing caller information blocks useful research, it can return a clarification question.
-
Plan what to investigate
The planner asks what could change Pine’s choice. Attractive example images are not enough: commercial rights, transparent output, browser integration, and reported failures could all matter. It chooses questions worth investigating, starts useful opening searches, and lets the researcher continue from the same conversation. That gives the research a purpose before more sources arrive.
What moves forwardThe researcher receives the plan and the evidence already found.
How this step works
The planner and reviewer is GPT 6.1 Sol; the researcher is Muse Spark 1.3 Contributor. They take turns in one shared conversation rather than exchanging replacement summaries. The plan can change when returned material reveals a new issue; it is not a fixed checklist copied from Pine.
-
Check independent sources together
The researcher looks for official documentation and licensing terms on the web. If original launch posts or practitioner discussions on X would help Pine, it searches there too. Independent questions can run at the same time; a useful result can be read while another search continues. Returned pages and attributed answers provide leads for closer inspection.
What moves forwardUseful findings lead the researcher to their original sources.
How this step works
Exa and Firecrawl handle open-web discovery and page reads; xAI searches X only. The models select complementary capabilities instead of asking every provider the same question. Seeker waits for returning results without repeated model polling. A provider’s answer remains a candidate, not automatic permission to deliver it.
-
Read what could change the choice
Imagine a comparison praises a candidate but leaves its commercial conditions unclear. The researcher opens the official license before recommending it to Pine. It reads useful material already available and fetches missing originals when needed. If the evidence reveals another important uncertainty, it investigates again. More research earns its place by changing the decision, not by adding volume.
What moves forwardThe researcher proposes a choice with its conditions and open questions.
How this step works
The license branch is hypothetical, not a reported vendor finding. Full returned text stays available behind labeled previews; reading retained material does not purchase it again. Summaries, excerpts, and original words remain distinguishable. Further investigation must address an important gap that existing material cannot settle, and the loop can repeat within the run’s boundaries.
-
Review the proposed answer
The planner now reviews the researcher’s proposal against Pine’s question and the sources. Are commercial rights clear? Does the suggested integration fit the editor? It can correct the answer or request more evidence. If a search service’s own answer already suffices, it keeps that answer intact; otherwise it combines the findings into a clearer answer for Pine.
What moves forwardThe reviewed answer advances, or an important gap restarts investigation.
How this step works
The researcher cannot deliver directly. An adopted provider answer keeps its wording and attribution; separately labeled, cited Seeker checks can add a condition that changes the decision. Local review does not automatically swap model roles. As the delivery window approaches, control returns to the reviewer before another research-model turn; an already-running call can still run out of time. Model judgment decides sufficiency, not truth.
-
Check where the support came from
Seeker checks the answer’s citations against material returned during Pine’s investigation. It refuses citation entries for sources it never received and checks quoted words against what the models read. This lets Pine inspect the support behind a recommendation. Finding a sentence in a license still does not prove that its conditions apply to Pine’s intended use.
What moves forwardThe answer carries source references with clear evidence labels.
How this step works
A mechanically verified quotation matches source words the models were shown. Provider-reported attribution records what a search service supplied without claiming Seeker recovered the quotation from the original. An excerpt or abstract keeps that label; a provider-written summary is not the page’s own text. These checks establish narrower facts than whether a recommendation is correct.
-
Return the answer and what remains open
Pine’s assistant receives the supported choice and any remaining questions. Commercial terms might be documented while performance on Pine’s own images remains untested; that limit belongs in the answer. If information from Pine is missing, Seeker asks for it. If research stops before completion, it says so. Pine can then decide what to try or verify directly.
What moves forwardPine gets a decision basis and a clear next step.
How this step works
The three outcomes are an answer, a clarification request, or an incomplete run. Deadline, cancellation, and unrecoverable failures retain partial records instead of fabricating a finished answer. The investigation record includes evidence, timing, and cost. Seeker researches the choice; it does not install the service or execute Pine’s product trial.
The system behind the story
Every piece has a job
Open a piece for its role, or a technology for the choice and tradeoff.
PeoplePerson and calling assistant
The person needs a decision; the assistant carries the question into Seeker and uses the returned result.
SoftwareSeeker
A local research tool. Its code executes calls, retains evidence, checks references, records costs, and controls stopping boundaries.
ServicePlanner and reviewer: GPT 6.1 Sol
Plans the investigation, checks the proposed answer against the original request and sources, and approves delivery.
ServiceResearcher: Muse Spark 1.3 Contributor
Conducts the intervening searches and reading in the same conversation. Its draft is a proposal for review.
ServiceSearch services: Exa, Firecrawl, xAI
Exa and Firecrawl find and retrieve open-web material. xAI investigates original posts and threads on X.
RecordsRetained research record
Keeps the request, returned material, proposals, final outcome, timing, and cost records available for inspection.
Why these technologies?
MCP: the assistant’s tool connection
- The job
- Carries one research request and its outcome between the calling assistant and Seeker.
- Why this choice
- The current product fits inside an assistant’s existing workflow through a narrow question-plus-context interface.
- The tradeoff
- The local Seeker process and client connection must be running. There is no separate hosted service to take over if they stop.
Two model roles through OpenRouter
- The job
- Sol plans and reviews; Muse Contributor handles intervening research. OpenRouter connects Seeker to both default models.
- Why this choice
- The current design shares one retained conversation. Documentation records that Muse became the default after long drafts and deadline failures with the earlier, still selectable MiniMax M3 worker.
- The tradeoff
- Model access and usable responses are required. Extra review can add time and cost; this split has not been shown to be universally better than one model or a direct vendor answer.
Exa and Firecrawl: open-web discovery and reading
- The job
- Find and retrieve relevant web material, including specialized code and research sources where appropriate.
- Why this choice
- They let Seeker investigate primary pages and distinct evidence needs rather than reducing every vendor to the same generic search.
- The tradeoff
- Access failures or missing material can leave gaps. A search result, summary, or abstract does not establish what a full source says.
xAI: research on X
- The job
- Find original posts, accounts, and threads on X; open-web reading belongs to other services.
- Why this choice
- The documented earlier mixed web/X call mostly searched the web. Restricting this capability preserves its distinct source role.
- The tradeoff
- If X evidence is required and unavailable, web coverage cannot silently replace it. The missing source requirement stays visible.
Python: execution and stopping controls
- The job
- Executes selected actions, records paid attempts, and controls deadlines, cancellation, and admission of new calls.
- Why this choice
- The implementation assigns meaning and judgment to models, while deterministic code owns these boundaries.
- The tradeoff
- The default deadline is ten minutes, not a promised duration. Ordinary cost controls stop new calls at known shared costs; unknown or already-running charges can exceed them. Optional strict mode can refuse calls without proven maximum-price bounds.
Retained sources and citation checks
- The job
- Keep returned originals available behind labeled previews and record what each citation was checked against.
- Why this choice
- The design preserves the difference between source words, excerpts, provider prose, and native attribution instead of blending them.
- The tradeoff
- Retaining a page is not the same as reading it. Exact quote occurrence is a narrower check than factual correctness or a valid recommendation.
Keep the boundary clear
What exists, and what comes next
Local research tool used by AI assistants
Implemented today
- The inspected implementation accepts a question plus optional context and uses one shared planning, research, and review conversation.
- It can choose complementary search capabilities, run independent calls in parallel, read retained material, and investigate further consequential uncertainty.
- Only the planning/review role approves delivery: an unchanged provider answer, a cited synthesis, or a clarification question. Interrupted runs remain incomplete.
- It retains evidence, timing, and cost records and distinguishes mechanically verified quotations from provider-reported attribution.
- Current code lets Sol continue with retained and newly arrived evidence after exhausted retryable research-model failures, without calling that failed worker again.
Limits of the current system
- These are verified implementation behaviors, not a new live run for this page. Current client processes may need a refresh to load changed code.
- Successful retained caller-reviewed examples do not establish universal correctness, predictable completion time, or an advantage over direct vendors.
- The sufficiency judgment belongs to a model. Citation checks do not establish that a claim is true or that its conditions apply.
- Authentication failures, context rejection, cancellation, and deadline exits remain incomplete. The worker-recovery path has controlled evidence, not a fresh live-outage demonstration.
- Ordinary spending controls are not guaranteed invoice ceilings. Repeatable model-cache savings also remain unproven.
Next, not yet established
- Compare the current conductor with native vendor answers and direct synthesis using matched questions and independent assessment of complete answers.
- Reduce repeated evidence proposals and final drafting while checking complete-answer usefulness, elapsed time, and cost.
- Broaden ordinary and deep-research validation, including contradictory sources and consequential gaps. Hosting and tenancy remain open choices, not shipped features.
Say it back
The version to remember
Seeker gives an AI assistant one research tool. It takes the person’s question and context, chooses suitable search services, and reads the evidence. A planner reviews a researcher’s work in one shared conversation, then keeps a sufficient vendor answer or synthesizes one with citations and gaps. Code controls execution and checks references and quotes. Those checks make support inspectable; they do not guarantee truth. If research cannot finish, Seeker says so.
Founder questions
Check your understanding
Why use Seeker instead of one search API?
It owns which capability to use, what evidence to inspect, and whether an important gap warrants another investigation. That is its intended contribution; a consistent measured advantage over simpler alternatives remains unproven.
Who decides when the answer is good enough?
The planner reviews against the original request and sources. Code checks boundaries and references, not semantic sufficiency. The stopping judgment still needs broader independent evaluation.
Why are there two models?
They have planning/review and research roles in one conversation. Muse is the current research default after recorded delivery problems with the earlier selectable worker. More review can add latency; this is not a proven universal optimum.
Does it always consult every provider?
No. It selects complementary capabilities for uncertainties that matter. Independent searches can overlap; follow-ups depend on what returns. xAI covers X, while Exa and Firecrawl cover open-web work.
What does a verified citation mean?
A mechanically verified quote matches source words the models saw. It does not prove a conclusion or its applicability. Provider-reported references and excerpts retain their explicit, narrower evidence labels.
What happens when a service fails or time runs out?
Other searches can remain usable after a capability refusal, with missing coverage disclosed. Sol can continue after exhausted retryable worker failures. Some failures and all deadline/cancellation exits remain incomplete; partial records survive.
Can I promise fast, cheaper, or better research?
Not across the board. Current evidence includes ordinary successful answers and multi-minute research with failures. The ten-minute default is a boundary, not a delivery promise, and ordinary spending controls are not a hard invoice guarantee.