Research Agent for Market Intelligence by Ugo ChukwuResearch Agent for Market Intelligence by Ugo Chukwu

Research Agent for Market Intelligence

Ugo Chukwu

Ugo Chukwu

Verified

Research Agent — Engineering Evidence-Grounded Market Intelligence

Role: Founding Lead Engineer Company context: Peerless Public reconstruction: Research Agent by Etherlabs Core disciplines: AI engineering, research orchestration, evidence synthesis, retrieval, claim governance, multi-tenant SaaS, evaluation, product engineering, technical leadership
Preview
I designed and built a research-intelligence system that converts fragmented market and customer material into evidence-linked claims, belief transitions, conflicts, knowledge gaps, and reviewable strategy inputs—then reconstructed its core architecture publicly with synthetic data and reproducible evaluations.
This case study describes work completed for Peerless and demonstrates it through a fresh Etherlabs implementation. The public repository contains new code and synthetic organizations, sources, claims, metrics, and screenshots. It contains no proprietary Peerless source, prompts, credentials, internal product names, or client identities.
Research Agent: turning mixed source material into defensible, reviewable intelligence.

The outcome

Research Agent turns scattered research material into a versioned intelligence snapshot that a strategy team can inspect and challenge.
Instead of presenting a confident summary with invisible sources, it makes the reasoning surface explicit:
what was directly observed;
what was inferred from patterns;
which sources disagree;
what remains unknown;
how fresh and representative the evidence is;
which belief transition the evidence supports; and
which claims still require human review.
The result is not an autonomous web-research demo. It is a research operating system designed around provenance, uncertainty, tenant scope, reviewer authority, and safe downstream handoff.
The research workspace puts synthesis, evidence quality, uncertainty, and review controls on one decision surface.

The problem: research volume is not research confidence

Growth and strategy teams rarely lack material. They have customer interviews, reviews, surveys, market notes, product documents, competitor material, performance summaries, and prior research.
The real problem is that these sources have different authority, freshness, coverage, and failure modes.
A repeated phrase in five duplicate documents is not five independent signals. A confident competitor claim is not customer evidence. A recent interview may be rich but unrepresentative. An AI-generated synthesis can sound definitive while silently blending observation, inference, conflict, and absence.
The engineering challenge was therefore larger than collecting pages and asking a model for themes. I needed to build a system that could answer:
Where did this claim come from?
Does the evidence support, contradict, or merely qualify it?
Is the conclusion observed or inferred?
Which segment or source is underrepresented?
Who is authorized to change the claim state?
What can safely move downstream?

My role and ownership

As Founding Lead Engineer at Peerless CMO, my ownership covered:
defining the research-intelligence product and system architecture;
prioritizing the source, synthesis, review, and handoff workflow;
designing the research orchestration and evidence models;
building source-quality, freshness, conflict, and insufficiency diagnostics;
modeling customer language, demand signals, proof requirements, and belief transitions;
designing safe-claim and downstream-readiness boundaries;
implementing backend and frontend product surfaces;
building tenant, actor, and role boundaries;
designing evaluation and negative-security coverage;
iterating against operational and production constraints;
delivering the intelligence into client-facing workflows; and
providing technical direction as the engineering team expanded.
I was the sole engineer through July 2026 and became technical lead after the team expanded. This is architecture and delivery leadership, not an inflated people-management claim.

System design: evidence before synthesis

The core workflow is:
define scope → collect in parallel → normalize and deduplicate → retrieve → synthesize → check support and conflict → human review → versioned snapshot
The system separates source processing, synthesis, epistemic checks, and reviewer authority.

1. Establish immutable actor and project scope

Every request begins with an authenticated actor containing organization and role. Project scope is derived server-side. A supplied identifier cannot grant access to another tenant.
Cross-tenant project and run identifiers return 404, preventing the API from confirming whether another organization’s resource exists.

2. Collect sources behind typed adapters

Source collection is modeled as a set of bounded adapters rather than one opaque scrape. Each result carries source type, availability, observed time, provenance, and quality metadata.
The public version accepts reproducible text ingestion instead of live third-party scraping. This keeps the demo deterministic while proving the ingestion and trust boundaries.

3. Normalize and deduplicate before counting support

Equivalent whitespace is normalized and content is hashed within organization and project scope.
normalized = re.sub(r"\s+", " ", payload.content).strip()
digest = sha256(normalized.encode("utf-8")).hexdigest()
key = (actor.organization_id, project_id, digest)
Stable source identity prevents duplicate material from artificially increasing evidence support.
Instruction-like text is flagged as untrusted evidence. Retrieved material can inform a claim; it cannot redefine the system prompt, remove citations, reveal credentials, or change authority.

4. Retrieve with provenance intact

The durable architecture combines full-text and vector retrieval over tenant-scoped evidence excerpts. Every candidate remains connected to its source, observed time, and project.
The goal is not merely to find relevant text. It is to preserve the chain from source to excerpt to claim so a reviewer can inspect the support.
Every research conclusion retains a path back to its source and evidence excerpt.

The claim model: confidence is not a status

Research Agent uses four explicit epistemic states:
Observed: directly supported by evidence.
Inferred: a defensible pattern, but not directly stated.
Conflicting: credible evidence disagrees.
Unknown: the available material cannot support the conclusion.
A confidence score alone cannot represent these differences. A high-confidence inference is still an inference. Two well-supported contradictory statements remain a conflict. Missing evidence does not become low-confidence truth.
Claim classification communicates the kind of knowledge the system has—not only how confident it sounds.
Authorized managers and reviewers can change claim status. Researchers can start collection and inspect evidence, but they cannot approve their own conclusions by changing the review state.
if actor.role not in {Role.MANAGER, Role.REVIEWER}:
raise HTTPException(status_code=403, detail="Reviewer permission required")
Reviewer authority is a backend contract, not a disabled frontend button.

Modeling belief transitions rather than collecting themes

A theme says what people discuss. A belief transition describes movement:
current belief → evidence or trigger → target belief
That structure is more useful to downstream strategy because it captures the psychological change the evidence supports.
For example, a synthetic buyer may move from “this looks like another generic product” to “this is built for my use case” after seeing a specific proof pattern. The system keeps the starting belief, trigger, destination belief, evidence count, and confidence separate.
Belief transitions turn research into a structured strategy input without generating final campaign execution.
This boundary matters. Research Agent produces strategy-ready evidence; it does not create final advertising copy, make media decisions, or publish externally.

Coverage, source quality, and knowledge gaps

The system treats missing evidence as product output.
Coverage summarizes whether required research domains are represented. Source-quality distribution shows which kinds of evidence dominate. Knowledge gaps identify underrepresented segments, stale material, missing proof, or unresolved disagreement and recommend the next research action.
This prevents a synthesis from appearing complete simply because the model produced a complete paragraph.

Tenant and role boundaries

The public implementation demonstrates three roles:
manager: start runs, review claims, and create snapshots;
researcher: start runs and inspect evidence, but not approve claims; and
reviewer: review claims, but not start collection runs.
The Supabase architecture repeats organization membership in row-level security policies across projects, sources, excerpts, runs, steps, claims, evidence links, conflicts, gaps, snapshots, and feedback.
Tenant isolation and reviewer authority are enforced across API and database design.
The migration and eight-assertion pgTAP suite are authored, but they were not executed against a live database for this Tier 1 release. I preserve that distinction rather than calling designed policies hosted proof.

Provider failure does not remove the research controls

The optional provider adapter has a bounded timeout and validates its response. If it is absent, slow, malformed, or unavailable, the system explicitly enters deterministic mode.
Deterministic fallback preserves the evidence, claim classifications, review permissions, gaps, and safe snapshot workflow. It does not pretend a provider ran.
This lets the repository remain locally demonstrable without consuming hosted infrastructure or model-provider resources.

Safe handoff stops before execution

A reviewed research snapshot is an internal, versioned artifact. It can become input to a separately governed strategy system, but Research Agent does not publish content, create ads, change campaigns, or execute external actions.
That separation makes the handoff inspectable: downstream systems receive classified claims, belief transitions, customer language, proof requirements, conflicts, and known gaps—not an untraceable paragraph.

Testing and evaluation

I designed the verification around the places research agents fail:
unsupported quotations, dates, numbers, and comparative claims;
duplicate sources inflating support;
observation/inference confusion;
conflicting and stale sources;
missing source coverage;
malicious instructions inside documents;
provider degradation;
cross-tenant identifiers;
role escalation; and
snapshots that imply external action.
As of August 11, 2026, the public repository proof includes:
13 passing API tests;
3 passing frontend interaction tests;
40/40 deterministic evaluation cases;
desktop and mobile local browser acceptance with no observed console warnings or errors; and
passing GitHub Actions web and API jobs at public commit 64b1f3f.
These are repository and CI results—not production traffic, model accuracy, or commercial impact.
The public proof is reproducible without claiming hosted production behavior.

Historical engineering scale

An August 11, 2026 private-source snapshot identified approximately 6,058 directly related lines across the scoped research subsystem.
That dated number describes engineering breadth in the private product. It is not the size of the public reconstruction and not a business-impact metric.
I deliberately exclude revenue, research-time reduction, accuracy uplift, campaign performance, and client outcomes because no retained approved source currently supports those claims.

What the public reconstruction proves

Research Agent by Etherlabs demonstrates:
a working React/Vite research command center;
a FastAPI/Pydantic API and generated OpenAPI contract;
signed, expiring synthetic sessions;
two isolated synthetic organizations and three roles;
deterministic source normalization, hashing, and deduplication;
untrusted-document instruction detection;
evidence-linked claim and belief-transition models;
provider degradation with deterministic fallback;
streamed run provenance;
reviewable claims and safe internal snapshots;
a Supabase/pgvector/RLS deployment architecture;
reproducible tests and deterministic evaluations; and
public GitHub CI.
Northstar Athletics, Harbor Home, all sources, evidence excerpts, claims, coverage values, findings, people, and screenshots are synthetic.
Mobile prioritizes research status and evidence review instead of reproducing the entire desktop command center.

The most important engineering decisions

1. Make provenance part of the data model

A citation added after synthesis is weaker than a claim built from evidence links.

2. Separate epistemic state from confidence

Observed, inferred, conflicting, and unknown communicate different kinds of knowledge.

3. Deduplicate before aggregation

Repeated copies of one source should not become independent support.

4. Treat missing evidence as output

Coverage and gaps tell the team where research should continue.

5. Separate collection from approval

Role boundaries prevent the same actor from silently turning an inference into approved truth.

6. Preserve controls during degradation

Fallback mode should keep provenance and review intact—not bypass them.

7. Stop at a versioned handoff

Research intelligence and live execution require different authority and evaluation systems.

What I learned

The hardest part of an AI research product is not generating a summary. It is designing the structure around the summary so another person can decide whether to trust it.
The quality unit is a reviewable research claim:
scoped to the correct organization;
connected to identifiable evidence;
honest about inference and conflict;
protected from duplicated or malicious source material;
reviewable by the right role;
explicit about what remains unknown; and
safe to hand off without implying external action.
That is the standard I bring to research, intelligence, and decision-support systems.

Explore the work

Company context: https://peerlesscmo.com
If you are building a research or intelligence product that must remain credible when evidence is incomplete, contradictory, or adversarial, this is the kind of architecture and end-to-end engineering ownership I bring to the work.
Like this project

Posted Aug 12, 2026

Developed Research Agent to synthesize fragmented market data into evidence-linked claims.

Likes

0

Views

1

Timeline

Mar 1, 2026 - Ongoing

Clients

Peerless