AI automation discovery is quickly becoming a more useful test of agentic AI than another coding benchmark. Instead of handing an agent a well-defined task, the bigger opportunity is to let it inspect approved work patterns, identify friction, recommend a solution, and—only after review—build it.

That is the premise behind a recent video from AI strategist Nate B. Jones, who gave Codex and Fable access to selected business files and communications, then asked each system to find and automate a meaningful problem. The two agents did not converge on the same answer—and that disagreement is the most interesting result. (youtube.com)

The real test was problem selection, not task completion

Most AI-agent demos begin with a clean request: build a feature, summarize research, update a spreadsheet, or draft a campaign. Jones inverted that workflow. He asked the tools to inspect how work happened and decide what was worth automating, with explicit limits on what they could access.

In his account, Codex selected a relatively bounded operational issue: improving the package of research and context handed into the content-production process. It was not the most ambitious choice, but it was concrete, buildable, and apparently completed cleanly in one pass. Fable, by contrast, identified a more strategic editorial problem: helping refine and prioritize story ideas before they enter production. (youtube.com)

That makes this less a head-to-head benchmark than a useful illustration of two distinct agent roles:

  • The execution agent finds a defined, low-ambiguity workflow and reliably completes it.
  • The discovery agent examines the surrounding system, frames a higher-leverage problem, and proposes where humans should focus next.

Both are valuable. But teams that measure only whether an agent finished a requested task may miss the larger productivity gain: reducing the human burden of diagnosing what should be fixed.

Codex vs Fable: execution reliability versus strategic framing

Jones’s conclusion was nuanced. He preferred Fable’s strategic instinct in this particular experiment because it surfaced a tool he considered essential, rather than merely convenient. At the same time, he described Codex as a smoother everyday working environment for execution, citing its dependable harness and lower-friction experience. Those are personal observations from one workflow, not proof that either product will produce the same result for every company. (youtube.com)

Still, the distinction lines up with how the platforms are being positioned. OpenAI describes Codex as an agentic system for end-to-end engineering work, including automations, code reviews, pull requests, refactors, and parallel workflows. It also supports reusable Skills that encode team standards and workflows. (openai.com)

Anthropic positions Claude Fable 5 for long-running, multi-stage knowledge and coding work, emphasizing proactive planning, unfamiliar tools, and reviewable deliverables. Its own guidance also highlights an “advisor” orchestration pattern: use a frontier model for strategy while a less expensive model handles more of the execution. (anthropic.com)

For founders and operators, the practical lesson is not “always use one model for strategy and another for building.” It is to separate those two jobs deliberately. A model that produces a brilliant diagnosis may not be the most economical implementation engine. A highly reliable builder may not independently select your organization’s most important bottleneck.

How to run an AI automation discovery sprint

Do not give an agent unrestricted access to Slack, drives, email, customer data, and production systems just to see what it finds. Start with a scoped discovery sprint that treats the agent as an analyst before it becomes an operator.

  1. Choose one business area. Limit the assignment to a specific workflow, such as content operations, sales follow-up, customer support triage, reporting, or onboarding.
  2. Create a read-only evidence set. Provide sanitized exports, a project folder, process docs, calendar patterns, and non-sensitive examples of recurring work. Exclude private chats, credentials, HR materials, financial data, and customer data unless there is a strong, approved reason.
  3. Ask for three ranked opportunities. Require the agent to explain the observed friction, affected users, expected value, implementation cost, dependencies, and failure modes.
  4. Force a human decision gate. Approve one problem definition before authorizing any external actions, writes, sends, purchases, deployments, or permission changes.
  5. Build a narrow pilot. The first version should have a small blast radius: a draft generator, a dashboard, a review queue, or a lightweight internal tool—not an autonomous system making irreversible decisions.
  6. Measure adoption, not novelty. Track time saved, error reduction, cycle time, revenue impact, and whether people actually keep using the tool after the initial excitement fades.

This approach also makes model comparisons more meaningful. Give two agents the same read-only evidence packet and identical scoring criteria, then compare their recommendations before comparing their code.

Guardrails are part of the product, not a preflight checklist

The video’s most important operational point may be its emphasis on walls: the creator excluded a personal Slack area from the agents’ investigation. That is the correct instinct. The more context an agent can inspect, the more useful its recommendations may become—but the potential privacy, security, and governance consequences rise too.

OpenAI’s own Codex safety material describes a model of constrained execution: sandboxing, approvals for higher-risk actions, network policies, and logs that show what an agent did. Its sandbox documentation similarly frames agent environments as controlled places to manipulate files, run commands, and generate artifacts. (openai.com)

At an organizational level, NIST’s AI Risk Management Framework offers a useful mental model: govern, map, measure, and manage risk. Applied to AI automation discovery, that means assigning an accountable owner, documenting accessible data and tools, testing outputs against clear criteria, and maintaining the ability to stop or roll back the automation. (airc.nist.gov)

A good discovery prompt should therefore include non-negotiables: what data is off-limits, whether the agent is read-only, where it may write files, which actions require approval, and what evidence it must cite for every recommendation. The goal is not to make agents timid. It is to make their autonomy legible and reversible.

The winning pattern is a portfolio of perspectives

The strongest idea from the Codex-versus-Fable experiment is that disagreement can be productive. When two capable agents review the same operating environment and identify different problems, that is not necessarily a failure of AI. It may expose a useful choice between immediate operational efficiency and a more strategic redesign.

Use one agent’s output as a challenge to the other. Ask the execution-oriented system to estimate and implement the strategic proposal. Ask the strategy-oriented system to critique whether the operational fix addresses root cause. Then let a human owner choose based on business value, risk, and adoption likelihood.

Conclusion: AI automation discovery needs human judgment upstream

AI automation discovery moves agents closer to the real work of operators: noticing repeated friction, forming hypotheses, and turning those hypotheses into tools. But the agent should not be the sole authority on what matters.

Jones’s Codex and Fable test is useful precisely because neither answer was universally “right.” One surfaced a dependable, bounded improvement; the other surfaced a potentially higher-leverage strategic opportunity. The best teams will build a repeatable process that invites both kinds of thinking—while keeping permissions narrow, decisions reviewable, and success tied to real workflow outcomes rather than impressive demos.