When people build an AI research product, the first architectural decision is often which agent framework to use. That decision quickly leads to more decisions: how to run the agent loop, connect the model, expose tools, preserve state, browse the web, recover from failures, and present the result.
But the agent runtime is not usually what makes a research workflow valuable. The value is in knowing where to look, which evidence to keep, how to evaluate it, and how to turn a pile of unstructured material into a useful conclusion.
That made me wonder: now that a capable harness such as Codex or OpenClaw already provides reasoning, web access, tool execution, filesystem access, and an interactive conversation, how many research projects still need to be standalone agents?
To test the idea, I took the workflow of a reasonably complex Reddit customer-research agent and rebuilt it as a Codex skill. The result is open source: you can inspect the complete Reddit pain research skill on GitHub.
What the research workflow does
The workflow is not a toy prompt that asks an LLM to browse Reddit and summarize a few posts. It performs a multi-stage research process:
- It turns a product or market idea into research objectives.
- It discovers and verifies relevant subreddits.
- It searches for posts and comments that contain customer pain points.
- It collects evidence with canonical source URLs.
- It removes duplicates and scores the findings.
- It clusters related problems into themes.
- It looks for commercial signals such as urgency, existing spending, and dissatisfaction with current solutions.
- It generates structured artifacts that can be inspected or processed later.
There is also a human approval checkpoint before the main research begins. The researcher can review the proposed communities and search direction before spending time on the full run.
This is the sort of workflow that would normally be presented as a specialized research agent. But most of its complexity is procedural: it needs a clear methodology, reliable tools, validation rules, and useful output formats. It does not necessarily need its own runtime.
Separate the capability from the methodology
It helps to separate two things that are frequently bundled together.
The harness provides general capabilities: it communicates with the model, runs tools, reads and writes files, browses sources, manages the conversation, and lets a person intervene. The skill provides the domain methodology: the sequence of research steps, the standards for accepting evidence, the approval checkpoints, and the expected outputs.
A custom agent combines both layers into a new application. That can be useful, but it also means rebuilding or integrating capabilities that a mature harness already has. For an operator-driven workflow, separating them is often enough: keep the general capabilities in the harness and make only the methodology specific to the problem.
The part I did not have to build
The most interesting part of this experiment is what disappeared. I did not need to create:
- a separate agent loop or runtime
- a separate LLM client
- nested agents
- a custom browsing and search layer
- a dedicated chat UI
- a new framework to orchestrate the research
- conversation and tool-execution infrastructure
Codex already provides those capabilities. The skill only needs to define how the research should be done.
The resulting architecture is roughly:
Codex harness
-> SKILL.md research workflow
-> deterministic helpers where needed
-> structured research artifacts
Instead of:
Custom agent
-> model integration
-> agent loop
-> tools and search
-> state management
-> UI
-> orchestration
-> report generation
That is a large reduction in code and infrastructure to own. It also narrows the surface area that needs to be tested. I can spend more time improving the quality of the research process instead of maintaining plumbing around it.
A skill is more than a long prompt
A skill packages domain-specific instructions, supporting scripts, templates, and references into a reusable workflow. In this case, SKILL.md explains the research process: which stages to run, what evidence to collect, when to ask for approval, how to judge relevance, and which artifacts to produce.
The model still reasons about ambiguous findings. The skill gives that reasoning a repeatable structure.
I kept small Python helpers for the parts where deterministic behavior matters, including:
- validating collected data
- calculating scores
- normalizing canonical Reddit URLs
- deduplicating evidence
- generating consistent artifacts
This split is important. Natural-language instructions are useful for interpreting messy discussions and identifying themes. Code is better for invariants that should behave the same way on every run. A skill can use both without requiring a new agent framework around them.
The workflow does not end with the report
A standalone research agent often has a narrow finishing point: it returns a report, and the run is over. Follow-up work may require starting another process, transferring context, or adding another feature to its UI.
Running the workflow inside Codex changes that. The report becomes the beginning of the next part of the conversation. I can ask Codex to:
- investigate one finding in more detail
- challenge an assumption in the analysis
- compare two problem clusters
- change the scoring criteria and regenerate the artifacts
- turn a promising pain point into a product specification
- start prototyping a solution in the same workspace
The research is no longer isolated from the work it is meant to inform. The same harness can move from discovery to analysis and then to implementation while keeping the relevant context available.
Turning an existing workflow into a skill
Codex includes a $skill-creator skill, so an existing workflow does not need to be repackaged manually from scratch. If a process already works in a conversation or project, Codex can help extract its steps, identify the deterministic parts, and organize the result as a reusable skill.
That is how I created this one. The full implementation, including the workflow and deterministic helpers, is available in the reddit-pain-research-skill repository.
This suggests a practical path for building specialized AI workflows:
- Work through the task interactively until the methodology is useful.
- Notice which instructions, checks, and output formats repeat.
- Move deterministic operations into small scripts.
- Package the methodology and helpers as a skill.
- Improve the skill using real runs instead of designing an agent platform first.
When a different harness—or a custom runtime—makes sense
Codex is not the only harness capable of running a skill. Projects such as Hermes Agent and OpenClaw also provide the general infrastructure around a workflow: an agent loop, tools, memory, skills, messaging integrations, and ways to run on your own machine or server.
They also cover use cases that an interactive coding harness may not. Hermes can run on persistent infrastructure, communicate through messaging platforms, execute scheduled tasks, and create or improve skills from experience. OpenClaw can operate as a self-hosted personal assistant, receive work through messaging channels, maintain persistent context, and run tasks through its embedded agent runtime.
So a requirement such as “this must run on a schedule” or “I want to reach it through Telegram” does not automatically mean that I need to build a custom agent. It may only mean that I should run the skill in a harness designed for persistent and autonomous operation.
The choice is better understood as two separate decisions:
- Which harness fits the operating model? Codex may fit an interactive research and development workflow. Hermes or OpenClaw may fit an always-on, self-hosted, messaging-driven, or scheduled workflow.
- Does the methodology need anything beyond a skill? The research instructions, validation rules, scripts, and artifact formats can remain a skill even when the surrounding harness changes.
What about security?
These security principles apply to Codex as well as autonomous harnesses such as Hermes and OpenClaw. The implementation differs between them, but the underlying decision is the same: which tools, files, networks, and credentials does this particular workflow need?
As with any automation that can browse the web, read files, or call external services, it is worth deciding what the harness should be allowed to do. This does not need to make the setup complicated or prevent people from experimenting with these tools.
Access can be introduced gradually. A useful first run might be interactive, read-only, limited to public web research, and restricted to a dedicated project directory. The user can review the proposed research plan and approve important actions before they happen. Once the workflow is understood and its outputs are predictable, selected steps can be automated.
This is the same gradual approach we already use with scripts, CI jobs, and third-party integrations. Start with a small scope, inspect the results, and expand permissions only when the benefit is clear. Useful safeguards include:
- begin with supervised runs instead of unattended execution
- use read-only tools where writes are not required
- require approval before commands, external actions, or destructive changes
- give the agent a dedicated workspace instead of a personal directory
- use task-specific credentials with limited permissions and short lifetimes
- add spending, time, and request limits for long-running tasks
- keep logs and review the generated artifacts before acting on them
A Reddit research workflow, for example, may need public web access and permission to write reports into one output directory. It probably does not need a personal browser profile, unrelated files, or unrestricted credentials. Removing those capabilities keeps the workflow easier to reason about without reducing its usefulness.
For unattended workflows or sensitive environments, stronger isolation can be added by running tools inside a container, virtual machine, cloud sandbox, or dedicated server. Only the required directories and credentials need to be made available there, and network access can be restricted when the task does not require it.
Codex uses sandboxing and approval policies for local execution. By default, its local workspace-write mode limits writes to the active workspace and keeps network access disabled; read-only mode is available when no changes are needed. Codex cloud runs tasks in isolated containers rather than on the user’s computer.
Hermes documents command approvals, tool controls, write-safe filesystem roots, filtered credentials, container backends, and an option to disable network access inside its Docker execution environment. OpenClaw can run file, process, and browser tools in an optional sandbox instead of directly on the host. These controls still need to be configured correctly, and the OpenClaw documentation explicitly notes that sandboxing is not a perfect security boundary for it.
The appropriate setup depends on the task. A supervised experiment using public information needs fewer controls than an always-on agent connected to production systems. The principle is simple: give the workflow the access it needs, introduce autonomy in stages, and increase isolation in proportion to the sensitivity of the data and actions involved.
Where existing harnesses stop being enough
A genuinely custom runtime becomes justified when existing harnesses cannot satisfy an important product, operational, or security requirement. That might include:
- a purpose-built interface and user experience are part of the product
- one service must safely support multiple customers with isolated data, credentials, quotas, and execution environments. In this case, some workflows need custom agent
- the workflow needs per-step retries, idempotency, recovery, or durable state across long-running operations. There are ways to manage this to some extend. But generally this can be true
- governance related centralized administration
- complex authentication flows that existing harnesses cannot support safely. but sometimes skills or MCP are available. So, make sure to verify
- strict isolation, compliance, auditability, latency, or deployment constraints require direct control of the execution layer
- the system needs application-specific observability or coordination with other production services
- the target environment has security requirements that do not permit a general-purpose agent harness
- the agent runtime itself is the product and must be embedded, distributed, or operated for other users
These are not merely requests for more tools. They change the execution and trust model of the system. Even in those cases, the domain methodology can often remain portable. Starting with a skill makes it possible to validate the workflow before committing to a runtime, and it keeps the valuable part of the system separate from the infrastructure used to execute it.
A better starting point
The useful question before building a specialized research agent is:
Does this use case require a new agent runtime, or does it require a domain-specific skill running inside an existing harness?
For this Reddit research workflow, the second option was enough. The skill contains the parts specific to the problem: the methodology, checkpoints, validation rules, scoring, and artifacts. Codex supplies the general capabilities around it.
This distinction changes where the engineering effort goes. Instead of starting with infrastructure, I can start by making the research methodology work. If that methodology eventually needs independent execution, a dedicated interface, or stricter operational control, it can grow into a custom application with evidence that the additional architecture is necessary.
A hybrid system is also possible. A custom application can handle the parts that are truly product-specific—such as authentication, multi-tenancy, scheduling, billing, durable state, governance, or the user interface—while delegating the research itself to a skill running inside an established harness. This preserves control where the product needs it without rebuilding the agent loop, tool execution, and reasoning environment.
The architecture does not have to be chosen once and kept forever. A workflow can begin as a skill, move into a hybrid system as operational requirements appear, and become a fully custom runtime only if those requirements eventually justify it. Keeping the methodology separate makes each of those transitions easier.
Many projects described as “agents” may actually be reusable workflows wrapped in infrastructure. Most of the time, running a well-designed skill inside a capable harness will be the easier solution. It requires less infrastructure, is faster to improve, and leaves room for a hybrid or custom system later. In some cases, the skill is not merely a prototype—it is the complete solution.
If you want to see how that looks in practice, explore the complete skill and its source code.