AI agent business ideas: validate the workflow first

Why it matters

The part of Greg Isenberg’s DevDay discussion that interests me most is the opportunity to take responsibility for a small, recurring job. Checking product records, preparing a status update or routing a request gives a builder something concrete to sell and a customer something concrete to evaluate.

New agent infrastructure can make those products easier to build. New distribution surfaces can help people encounter them. Neither establishes demand on its own. I would treat Greg’s billion-dollar projections as a thesis about the market, then evaluate an individual business through customer access, delivery quality and repeat usage.

The episode also needs a dated update: it describes the Decisions API as a limited preview, while OpenAI’s changelog records general availability on October 22, 2026. Product access can change between watching a launch discussion and shipping an application. The useful habit is to turn the episode into a list of hypotheses, then check the current implementation conditions. OpenAI API changelog.

Key points

• 11:43 Specialist knowledge can become product value. Greg points to proprietary information, workflow expertise, external systems and measurable outcomes. For a small team, knowing how a particular customer handles exceptions could be a practical advantage.
• 12:51 The complete loop matters. A trigger creates work, a decision selects the next step, an action changes something and feedback establishes whether it helped. This gives builders a useful boundary for defining a product and measuring its performance.
• 02:48 Plugins could become an execution channel. Greg expects personal agents to select services that fulfill requests. The practical implication is to describe a capability precisely: what it does, what inputs it needs and what outcome it returns.
• 05:35 Bounded decisions fit many operational tasks. Classification and routing benefit from explicit choices and criteria. The opportunity is to improve a particular decision inside an existing process and evaluate it against actual examples.
• 06:42 Computer use expands the range of reachable work. Agents that operate interfaces can attempt tasks across websites and applications. That creates a delivery question: how will the product verify completion and recover from interruptions?
• 09:27 An existing ChatGPT plan could reduce onboarding friction. Greg’s free-core proposal is an interesting business hypothesis. Its economics depend on the integration’s actual eligibility and the costs the application still carries.
• 13:59 Physical services could become callable workflows. Connecting agents with human specialists requires more than a directory. Scope, availability, fulfillment and evidence of completion become part of the product.
• 15:03 Agent discovery needs outcome measurement. Greg proposes analytics for understanding which tools get selected. I would connect selection to execution and customer acceptance so that visibility improvements can be assessed commercially.

How to apply

AI agent business ideas need a narrow job

Start with work someone already performs regularly. “Check new product records before they enter the catalog” is a useful starting point: it has an input, a recurring moment and a reviewable output.

Ask five people who do that work to walk through a recent example. Find out how long it took, which errors caused rework and who approved the result. Then ask for a specific commitment: would they provide a sample batch and pay for a supervised pilot? Access to examples and a named buyer make the next development decision much easier.

I would avoid starting with a broad promise to automate an entire department. A narrow job lets the buyer compare the proposed service with something they already understand and budget for.

Score candidate workflows

Compare three ideas using the following scorecard. This is an additional screening method proposed here, rather than a framework from the episode.

| Criterion | 0 points | 2 points | |---|---|---| | Frequency | Rarely occurs | Happens every week | | Access | Required inputs are unavailable | Authorized samples and access exist | | Verification | Quality is mostly subjective | An objective check is possible | | Exceptions | Every case needs fresh investigation | Common patterns are understood | | Buyer | Nobody owns the budget | A responsible buyer will test it |

Give intermediate situations one point. Use the total to compare opportunities, while resolving missing access or an absent buyer before committing to development. A high score is a reason to investigate further; evidence of demand comes from customer behavior.

Specify the whole delivery loop

For a catalog checker, an uploaded spreadsheet triggers the job. The decision identifies missing or incompatible attributes. The action prepares corrections in a review queue. Feedback records what the reviewer accepted, changed or rejected.

Decide what happens when information is missing and how the application prevents duplicate processing. I would use a stable integration where one is available and add interface operation to cover the remaining steps.

There is an implementation detail worth handling explicitly with hosted browser execution: approving access to a website does not enforce confirmation before each individual action. Mandatory review needs restrictions in the execution environment and available permissions. Agents API computer use documentation.

Price completed work, including human effort

Consider an illustrative workload of 200 tasks per month at eight minutes each. Reducing human involvement to three minutes per task releases roughly 16.7 hours a month. That measures additional capacity. Its financial impact depends on whether the team uses it to serve more customers, reduce overtime or handle other work.

Estimate variable costs across model usage, tools, hosting, retries, human review and support. For example, $500 in monthly revenue with $180 in variable delivery costs leaves $320 before fixed expenses and customer acquisition. These figures are hypothetical. Measure your own costs and calculate implementation effort separately so an apparently healthy subscription does not conceal an expensive setup process.

Check the billing assumptions behind ChatGPT sign-in, too. Identity and plan usage require different permissions. Commercial access is currently limited to selected partners, and plan usage depends on eligibility and authorization. Confirm your application’s access before building a free offering around it. Official sign-in quickstart.

Offer a pilot with an acceptance agreement

A first proposal can cover two weeks, one task category, a volume limit and a named reviewer. Agree in advance on the measurements: total human time, correction rate, accepted outputs and cost per completed task.

For agent discovery, test direct requests, indirect requests and requests the tool should decline. Those categories also appear in OpenAI’s plugin testing guidance. I would begin with 30 representative requests and record tool selection, execution and acceptance as separate events. Official plugin testing guide.

This gives the analytics opportunity in the video a practical starting point: a repeatable test that catches a useful tool becoming harder to select or less reliable after an update.

At the end of the pilot, ask the customer to continue paying based on the recorded outcome. If review still takes as much effort as the original task, narrow the scope and test again. Expand once the customer repeatedly accepts the delivery and the economics support serving them.