Key facts
| Pattern | Plan → gather → verify → synthesise with citations |
| Runtime | Function calling loop on /v1/chat/completions (live) |
| Long context | plugsky-longctx for synthesising many gathered sources |
| Models | 30+ models behind one endpoint, route per stage |
| Provenance | Every claim linked to a source ID in structured output |
| Guardrails | Sub-question, tool-call and time budgets enforced in code |
| Observability | Per-turn traces with queries, sources and claim mappings |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- Plan sub-questions explicitly; unplanned research wanders and duplicates work.
- Gather through tools so every source has an ID you can cite and audit.
- Verify claims against sources before synthesis — never after.
- Budget sub-questions and tool calls so runs terminate predictably.
- Store claim-to-source mappings with the brief for review and reuse.
How it works, step by step
- Define the deliverable — a brief, a comparison table or a set of answers — and the source types that count as evidence.
- Expose source tools: internal document search, database queries and approved external feeds with typed schemas.
- Implement the planning step: decompose the question into sub-questions and assign tools to each.
- Gather in parallel where possible, storing every result with a stable source ID and retrieval timestamp.
- Add a verification step that checks each claim against the gathered evidence and flags unsupported statements.
- Synthesise with a long-context model, requiring inline citations mapped to source IDs.
- Review traces and outputs against a fixed set of research questions, then widen access.
Try it yourself
Open the agent workflow designer →
Plan, gather, verify, synthesise
Research is a pipeline before it is a conversation. Planning produces sub-questions; gathering collects evidence with IDs; verification checks that claims are supported; synthesis assembles the brief. Running these as separate stages with explicit contracts makes the output auditable and the failures locatable.
Plugsky's live function calling supports the gather loop directly: pass a tools array on /v1/chat/completions, execute the returned calls against your sources, append results and continue. Long-context models such as plugsky-longctx handle the synthesis stage where many sources must be weighed together.
Tools and source discipline
Research quality collapses without source discipline. Every gathered item should carry a stable ID, a title, a timestamp and enough text to verify a claim. Tools should return trimmed, structured results rather than raw dumps, and the agent should record which source supports which claim.
- Approved sources: restrict tools to feeds and systems you trust, and label source types.
- Timestamps: store retrieval time so recency can be judged at synthesis.
- Deduplication: collapse near-identical sources to avoid inflating confidence.
- Refusals: allow the agent to report insufficient evidence instead of filling gaps.
Quality control for research output
Judge the output on three axes: coverage (were the sub-questions answered), support (is every claim traceable to a source) and calibration (does the brief distinguish strong from weak evidence). These are measurable with a fixed question set and human review, which is how you improve the agent without guessing.
Bound every run: a maximum number of sub-questions, tool calls and elapsed time. Trace each turn with the query, the sources returned and the claims mapped to them, so a weak brief can be traced to planning or gathering rather than treated as a black box. Route extraction and filtering to small models and synthesis to stronger ones, and keep the whole pipeline inside your chosen region, including on-prem where sources cannot leave the network.
Honest comparison
| Concern | Plugsky research agent | Manual research | Search plus summariser |
|---|---|---|---|
| Planning | Explicit sub-questions and tool assignment | Analyst judgement | None |
| Provenance | Source IDs on every claim | Notes and links | Often missing |
| Verification | Dedicated check stage | Reviewer reads sources | None |
| Synthesis | Long-context model over gathered evidence | Human writing | Single-pass summary |
| Audit | Per-turn traces and claim mappings | Working files | None |
Frequently asked questions
What can a research agent realistically do?
Gather and organise evidence, compare sources, and draft a cited brief. Judgement calls about significance and recommendations still belong to the analyst.
How do we stop fabricated sources?
Only cite from gathered results with stable IDs, and run a verification stage that rejects claims without supporting evidence. The agent should be able to say the evidence is insufficient.
Is function calling live?
Yes. OpenAI-style function calling and streaming are live on chat completions, which is the primitive the gather loop uses.
How many sub-questions should it plan?
Keep it bounded — typically a handful per run — and cap tool calls and elapsed time. Unbounded planning is the main cause of runaway cost and latency.
Which models fit each stage?
Small models for query generation, extraction and filtering; long-context or frontier models for synthesis. 30+ models share one endpoint, so routing is configuration.
How should we evaluate research quality?
Score coverage of sub-questions, support for every claim and calibration between strong and weak evidence, using a fixed set of questions reviewed by analysts.
Can it use internal sources only?
Yes, and that is often the right starting point. Expose internal search as a tool and add approved external feeds only when the workflow requires them.