A production market research agent is not a clever prompt that browses the web twice a day. It is a small data pipeline with an agentic interface: scheduled execution, source selection, freshness windows, citation capture, deduplication, rendering, delivery, and operational controls.
That was the core lesson from a recent OpenClaw build for a healthcare-focused investment team. The team did not need a demo that answered one impressive question. They needed a system that could run every morning and evening, produce a polished brief, preserve evidence, and deliver it where the team already worked.
The production framing
Research agents fail when they are treated as memo-writing prompts. They get reliable when the agent produces structured content and the host system owns scheduling, rendering, delivery, and state.
The Architecture in One Pass
The system ran OpenClaw on a dedicated local host, with a market research agent configured around Claude Sonnet, approved third-party APIs, and a controlled runtime. Host launchd jobs triggered morning and afternoon brief windows. The agent researched the window, wrote structured JSON, appended source-tracker rows, and advanced a watermark.
A Python renderer turned the JSON into a Typst-generated PDF with references, flags, source links, and consistent layout. After render, automation uploaded the PDF to SharePoint and posted a link into Microsoft Teams.
Research
Claude Sonnet plus approved search sources, temporal queries, freshness rules, and deduplication against prior runs.
Render
Structured brief JSON converted by Python and Typst into a polished PDF with references and review flags.
Deliver
Microsoft Graph uploads the PDF to SharePoint; the Teams bot posts a clickable link to the research channel.
Third-Party APIs Are Part of the Product
The agent integrated several external systems: Anthropic for model inference, Tavily for search, Microsoft Graph for SharePoint delivery, and Teams Bot Framework for channel messaging. Each integration had a different failure mode and security boundary, so treating them as interchangeable "API calls" would have been a mistake.
| Integration | Role | Production concern |
|---|---|---|
| Anthropic / Claude | Research, synthesis, and structured JSON output | Cost control, prompt discipline, continuation behavior, and source fidelity |
| Tavily | Search discovery over approved public sources | Freshness limits, missing publication dates, and careful citation handling |
| Microsoft Graph | SharePoint upload and folder management | App-only auth, scoped site access, idempotent delivery, and retry-safe markers |
| Teams Bot Framework | Interactive mention path and scheduled brief link posting | Channel binding, mention gates, authorized users, and reply egress controls |
Structured Output Beat Pretty Prompting
The early temptation was to ask the agent to write a polished report directly. That is the wrong boundary. Agents are good at selecting and summarizing content; layout engines are better at layout. The system moved to a structured JSON contract so the agent owned content and the host renderer owned presentation.
Agent responsibility: items, sources, dates, flags, standings, and references in a valid JSON shape.
Host responsibility: typography, page breaks, references table, footer, flags page, and PDF generation.
Operational benefit: schema drift can be detected and logged instead of silently turning into a bad PDF.
This separation made the system much easier to harden. When a model nested a field incorrectly or produced a variant shape, the renderer could recover, warn, and keep the run visible instead of failing silently.
Memory Started as a Tracker
For a daily research workflow, "memory" does not need to start as a vector database. The first useful version was an append-only tracker: every evaluated reference, whether used or dropped, became a JSONL record with reason, category, timestamp, source, and status.
That simple tracker did three important jobs. It let the agent deduplicate repeat coverage. It gave the team a CSV view of what the system had considered. And it created a migration path toward a more structured database later, without overbuilding the first release.
The Security Layer Had to Be Real
This was a local enterprise deployment, so the security model mattered. The OpenClaw runtime sat behind Pipelock egress controls, with strict allowlists, TLS interception where appropriate, and explicit handling for Microsoft reply traffic. Secrets were routed through Azure Key Vault and certificate-based identity. The production repo moved the running system into client-owned source control with deploy lanes and runbooks.
That work is invisible when the brief lands correctly. It is also what makes the system safe enough to keep running.
Source lists, Teams channels, SharePoint locations, and runtime tools were all explicit rather than implied.
Tracker rows, render warnings, delivery markers, and run logs made each scheduled brief inspectable.
The final shape included a private production repo, deploy notes, and operator runbooks so the system could survive beyond the initial build.
The Takeaway
The best research agents are boring in the right places. They run on a schedule. They remember what they already covered. They cite sources. They render consistently. They deliver to the systems people already use. And when something goes wrong, there is a log and a recovery path.
That is the difference between an impressive answer and a production agent.
Building an internal research agent or secure agent workflow? We help teams move from prototype to production-grade operation.
./see-services