Build a Research Agent with Model and Social Signals: A SandBase Pattern
A practical SandBase pattern for combining X discovery with model and search APIs while preserving evidence, source boundaries, and human approval.
Build a Research Agent with Model and Social Signals: A SandBase Pattern
The first version of a research Agent often looks impressive: search X, ask a model for a summary, send the paragraph to Slack. Then somebody asks, “Which post supports that sentence?” The answer is usually buried in a prompt log, if it exists at all.
The fix is architectural, not rhetorical. Keep social discovery, source retrieval, model reasoning, and publication as separate steps with typed handoffs. SandBase is useful here because one workflow can reach model and real-world API capabilities, while the evidence record remains yours to inspect.
Key takeaway
- Treat social posts as leads and primary pages as evidence.
- Pass a small evidence packet to the model instead of an unbounded feed.
- Make conflicts and unknowns first-class outputs.
- Keep publishing, posting, and production changes behind explicit approval.
Start with a research contract
Before choosing tools, define what a “good brief” contains:
{
"question": "What changed in the provider's API this week?",
"claims": [],
"sources": [],
"conflicts": [],
"unknowns": [],
"retrieved_at": "2026-08-25T10:00:00Z",
"status": "needs_review"
}This record has an important property: an empty claims array is acceptable. A research Agent should be allowed to conclude that the evidence is insufficient instead of filling the shape with confident prose.
Choose tools by job, not by brand
The SandBase Twitter catalog exposes separate search, trends, tweet detail, profile, media, and posting routes. The search model page makes the keyword and search-type inputs visible.
Figure 1. Separate routes let the policy distinguish read-only discovery from side-effecting posting.
Use the route that matches the question. Search finds candidate posts; tweet detail verifies a specific post; a model or web-search API can compare the post with an official document. Do not give the Agent every route just because they share an account.
Figure 2. A bounded search input makes the Agent’s discovery step inspectable and repeatable.
The evidence packet is the handoff
Normalize each result before the model sees it:
{
"id": "tweet-or-document-id",
"title": "short label",
"url": "https://source.example/item",
"publisher": "official account or site",
"published_at": "2026-08-25T09:40:00Z",
"excerpt": "relevant text only",
"source_kind": "social_lead",
"retrieved_at": "2026-08-25T10:01:00Z"
}Keep social leads and primary documents distinguishable with source_kind. A model can then say “the social lead claims X; the official page confirms Y” instead of blending them.
Reason in two passes
Pass one classifies evidence: relevance, source type, date, and claim candidates. Pass two answers the research question using only selected records. This is less flashy than sending the whole timeline to a large model, but it reduces prompt injection exposure and makes the cost predictable.
Ask for a structured result:
- supported claims, each with source IDs;
- conflicts, with the exact fields that disagree;
- unknowns and the next cheapest verification action;
- a confidence label tied to evidence coverage, not model tone.
The phrase “confidence 0.9” is not a citation. Store why the label was assigned.
Give the Agent a stop condition
Research loops need a budget. Stop when the question has enough independent primary support, when the candidate set is exhausted, or when the next action requires approval. A loop that keeps searching until the model sounds satisfied is not a research policy.
The SandBase Docs are the current setup reference for authentication and API calls. Keep credentials on the server side and pass only selected fields to the reasoning step.
Figure 3. The setup surface belongs in the implementation handoff; it should not be hidden inside an Agent prompt.
Approval boundaries are part of the design
Reading a post is reversible. Posting a reply, creating a ticket, changing a model route, or publishing a brief is an external side effect. Put those actions behind a reviewable draft, a separate tool permission, and an explicit approval event.
This is also where SandBase’s product boundaries matter. SandBase can connect the Agent to models and real-world APIs; it does not decide which provider statement is true, and it should not be described as owning a third-party source.
A production scorecard
- Citation coverage: every published claim points to one or more source IDs.
- Conflict recall: known disagreements remain visible after summarization.
- Freshness: each record has a retrieval time and source publication time.
- Cost: model tokens and external API calls are measured per completed brief.
- Safety: side-effecting tools are absent from the default research profile.
- Replay: a reviewer can reconstruct the evidence packet used for the answer.
I would ship a smaller Agent that passes this scorecard before adding more tools. More connectors increase the number of ways a polished answer can become untraceable.
