How I build
Give AI a business decision worth solving
A practical brief can create room for parallel AI work. A hypothetical launch shows the opportunity, the coordination cost and when a simpler task needs less.
Published: Updated:

In this article
The most useful thing I can give an AI system is a decision worth making. “Research the market” leaves it with an activity. “Work out whether this product is ready for a small UK launch, and what would change that conclusion” gives the work a purpose.
My role is to define that purpose and the business meaning of the result, while leaving the system room to choose a method. That is the approach I am developing for AI business systems. It does not mean specifying every search, document or intermediate step. The opportunity is to let several useful lines of work move at once without losing the decision they serve.
Give the system a destination
Consider a hypothetical founder preparing a subscription product for a new market. There is an existing product, a limited launch budget and a choice: open a small pilot now, adapt the offer first, or postpone. The examples below describe a proposed workflow, not a launch I have delivered or a measured revenue result.
A weak brief asks for competitors, pricing, customer research and a launch plan. It can generate four impressive documents that never meet. The pricing work assumes one customer segment; the competitor report describes another; the launch plan silently selects a third.
I would start with the choice. Which customer problem is the pilot supposed to address? What can the business commit? What would make an early launch worth learning from? A useful result might be a recommendation between the three options, an editable assumptions model and the smallest pilot that could resolve the main uncertainty.
The brief gives a business outcome, alternatives, starting evidence and an action boundary. It leaves the system free to choose the research sequence, analytical method and division of work. If it discovers a better way to answer the decision, there is room to use it.
Parallel work should bring different information to the choice
I would split this example by questions whose answers could change the recommendation. One agent examines the target customer's problem and evidence of existing alternatives. Another investigates what delivering the proposed offer would require. A third constructs a simple model of the assumptions under which each option makes sense. A fourth challenges the strongest emerging recommendation.
They do not need to wait for a completed market report before doing anything useful. Delivery research can start from the same product description. The model can begin with explicit ranges rather than invented certainty. The critic can identify the assumptions that would make a confident recommendation fragile.
| Question | Useful output | What it can change |
|---|---|---|
| Why would a customer switch? | Evidence of the problem and current alternatives | Target segment and offer |
| What must the product deliver? | Dependencies, effort ranges and constraints | Pilot scope and timing |
| When does the pilot make sense? | Editable assumptions and sensitivity | Launch, adapt or postpone |
| What would overturn the recommendation? | Strongest counterargument and a discriminating test | Next experiment |
The synthesis matters more than collecting four outputs. Suppose demand looks plausible, but the attractive offer depends on an integration that cannot be prepared within the budget. That dependency should change the recommendation. It should not survive merely as a footnote to an otherwise enthusiastic launch plan.
The tradeoff is between freedom and coordination
Detailed instructions make activity easier to predict. They can also freeze an early guess about the right method. Broad freedom allows a better route, but creates a coordination cost: agents may use different customer definitions, dates or assumptions.
I would spend that coordination effort on a few shared facts: the product version, target customer, budget, decision date and meaning of the proposed pilot. Intermediate hypotheses can differ. Foundational inputs need a common reference. If one agent discovers that an input is wrong, the finding should reach the other affected work rather than remain inside its own report.
There is also a cost to additional parallelism. Another agent is useful when it brings different evidence, expertise or a serious competing explanation. Repeating the same search four times is not automatically four times more informative. I would ask what decision could change because of the additional lane.
Turn uncertainty into the next piece of work
A model can make the choice easier to inspect without pretending to forecast the future. In this example, the useful question is not “What revenue will we earn?” It is “Which assumptions make the pilot worth attempting, and which assumption matters most?”
If the recommendation only works when customers adopt quickly, the next output should be a way to test demand. If delivery effort dominates, it may be a technical investigation. A large market description would not resolve either uncertainty on its own. This is the entrepreneurial work: deciding which unknown deserves attention now.
Chip Huyen's explanation of agents connects their capabilities to the environment, tools and planning. That is a useful technical background for giving the system a task it can actually act on. My launch example is my own proposed application, not an outcome reported in her article. Agents, Chip Huyen, 7 January 2025.
When this approach is unnecessary
A simple, reversible transformation does not need a miniature strategy exercise. If the task is to reformat an existing table or translate an approved paragraph, give the system the input, the desired output and the relevant constraints. Parallel research would add friction without improving the result.
The fuller approach becomes useful when several uncertainties interact and the business has a real choice to make. I want the AI to do more of the investigation, comparison and preparation. My contribution is to make the outcome meaningful enough that the system has something worth solving.