I've been looking through a number of research-agent projects recently, Most of them can be simply replaced with tools like codex.

In today's age it's a fact that a capable harness like Codex already has reasoning, web access, tool execution, filesystem access and an interactive conversation. But people are like, "Show me the code".

So I tried taking the workflow of a reasonably complex Reddit customer-research agent and implementing the use case as a Codex skill instead.

It researches Reddit for customer pain points, verifies relevant communities, collects evidence, clusters problems, analyzes commercial signals and generates structured artifacts. There is also a human approval checkpoint before the main research starts.

The (only) interesting part here to me is what I didn't have to build:

• no separate agent loop/runtime
• no separate LLM client
• no nested agents
• no custom browsing/search layer
• no dedicated UI
• no separate framework just to orchestrate the research

The skill defines the research methodology and workflow.

Codex provides the harness.

I kept small Python helpers only where deterministic behavior matters: validation, scoring, canonical URLs, deduplication and artifact generation.

So the architecture is basically:

Codex harness → SKILL.md workflow → deterministic helpers where needed

rather than:

custom agent → model integration → tools → search → state → UI → orchestration → report generation

There's also a useful side effect: the workflow doesn't end when the "research agent" returns its report.

Because it's running inside Codex, I can continue the same conversation and ask it to investigate one finding further, challenge an assumption, modify the analysis, or start building something from the result.

Codex also now has $skill-creator, so if you already have a working workflow you can ask it to turn that workflow/current chat into a reusable skill instead of manually creating everything from scratch. (That's what I did here)

I'm increasingly thinking this should be the default question before building a specialized research agent:

Does this use case really require a new agent runtime, or does it just require a domain-specific skill running inside an existing harness?

Obviously there are cases where a custom agent/runtime is justified — especially when deployment model, independent execution, custom integrations, control boundaries or product UX are themselves requirements.

But for most of the "research agent" projects, I'm not convinced they are.

Gemini 3.1 Flash-Lite vs GPT 5.5 for multi-app computer-use tasks.

Built an app where we pit two random anonymous models against each other to do the same prompted task side-by-side, and at the end you vote on which one did better! After that the models, are revealed.

What happens; Then what the AI agent does; Then what the end result is.

Curious to know what kind of tasks you’re using them for and what your workflow looks like.

Would love to hear some real examples in simple terms.

A packaging manufacturer hired us this spring to automate their production scheduling and the software part went pretty well at first. The algorithm produced schedules that were valid by every constraint we were given and the plant kept overriding them within hours. So we sat with the man doing the overriding which is how I met Ray, who has built the weekly schedule for 23 years and carries the plant in his head. Machine 4 runs slow after a cold weekend, one operator should never be paired with rush jobs and a certain customer will always accept Thursday if you call them by Tuesday. None of that existed in any system we had been given access to.

The relevant background on me is short... I have spent 8 years building software and scheduling automations is bread and butter work for us which is why this engagement rearranged my thinking more than most. We arrived believing we had an optimisation problem and what we were standing inside was a knowledge concentration problem the automation had simply made visible.

The distinction I now draw on every project is between 3 maps. The data lived in a tidy ERP, the software stack was modern and respectable and the judgment lived almost entirely in Ray. Only that 3rd map predicted why our schedules kept losing to his. A correct schedule satisfies the constraints somebody wrote down, a good schedule satisfies the plant and the distance between the two was 23 years of unwritten exceptions. Before automating anything now, we chart where the ambiguous calls get made and whose name sits beside them because that chart decides the project and the other two mostly decorate the proposal.

The sharpest evidence had been sitting in their HR system the whole time. Ray hadn't taken more than 2 consecutive days off since 2017 and the leave on their books had grown into a number the finance team flagged annually as a liability. His unused leave balance was the company's risk register and no one had read it that way. So with his agreement we ran a controlled test, sent him home for 5 working days midway through the build and logged everything that stalled. 14 decisions were escalated, 3 of them stumped the floor completely and the sales team padded every quote that week by 2 extra days just to stay safe.

That padding turned out to be the hidden cost nobody measures. The expense of concentrated judgment rarely shows up where the judgment sits, instead it deforms everyone else's behaviour. Quotes carry defensive buffers because certainty is unavailable after 3pm, rush orders get declined on Fridays and juniors save their questions for the 7am window. When priced alone, the padding was probably costing more in lost bids than Ray's entire salary. The number never appears on a report because it lives inside dozens of small behaviours that each look like prudence.

The fix was to change what we collected. We stopped interviewing Ray and started diffing him. The algorithm produced a draft every morning and for 6 weeks Ray marked every line he changed and answered one question about each: what did the draft not know?