Oracle: from answers to tasks

Models are becoming increasingly capable of answering questions. A stronger answer, however, does not naturally become completed work.

When someone says, “research this market,” “develop a complete proposal,” or “turn this idea into something usable,” they are not handing over a sentence that needs to be completed. They are handing over a goal. A goal rarely has one predetermined path, and it rarely ends with a single generation. It requires gathering information, understanding materials, choosing tools, producing intermediate results, and changing direction as new evidence appears.

That was the starting point for Oracle at Flowith. We were not trying to make a chat box say more. We wanted AI to keep working toward a goal.

The unit of the product should be the task

Conversational products are usually organized around messages: a user sends one, a model returns one, and the interaction is complete. That structure works well for questions and answers. It does not represent the state of real work very well.

Work can be active, waiting, failed, revised, or complete. It may produce several files, depend on an earlier result, or reveal that the original problem was framed incorrectly. If the product stores only a sequence of messages, these states end up hidden inside prose for the user to interpret and manage.

Oracle therefore expands a goal into tasks. A task is not there to display an impressive-looking checklist. It gives the system a working account of what it is solving, what it has learned, and why the next action is worth taking.

This may look like a change in data structure, but it changes the relationship between the product and the model. The AI is no longer responsible only for producing content. It begins to take responsibility for moving the work forward.

An agent is not a longer prompt

The tempting way to build an agent is to place every requirement inside one enormous prompt: analyze, plan, call tools, retry failures, and assemble a final answer.

That approach deteriorates as the task becomes longer. The model must understand the goal, remember the process, manage tool results, and handle exceptions at the same time. More context is placed into the same act of inference. The system appears more complete while becoming more fragile.

We came to understand Oracle as several cooperating responsibilities:

• planning turns the goal into an action that can be advanced now;
• tools search, read, generate, and transform concrete material;
• state preserves what happened and what remains unresolved;
• feedback lets the user change the goal without starting over.

The names of these parts matter less than the separation itself. The model exercises judgment; the surrounding system makes it possible for that judgment to continue.

A plan is a hypothesis

Our first instinct was also to have AI create a complete plan and then execute it step by step. It introduced order and made complex tasks feel controllable for the first time.

But a plan should not become a script the system must obey. Search results can overturn an assumption, a tool can fail, and the user can change the request halfway through. If an agent faithfully executes its original steps, it may complete the plan without achieving the goal.

A plan is better treated as a working hypothesis. It explains how the system currently believes it should proceed, while remaining open to being changed by new results.

This means a tool call does more than produce output. Its result must return to the decision process and change the system’s understanding of the task. Only then does the agent become more than an automated sequence. It continues to make decisions through the work itself.

Files are part of the process

Complex tasks rarely end as a paragraph of text. Research produces sources and conclusions. Creative work produces images, webpages, or documents. Later actions need to reuse what earlier actions created.

When files remain attachments beside a transcript, an agent cannot easily understand their relationships. It needs to know where an artifact came from, which problem it addressed, whether it is still valid, and what should use it next.

We therefore began treating intermediate artifacts as part of task state. They are not merely deliverables. They are also external memory through which the system can continue thinking.

This changed how I thought about context. The deeper problem is not only how many tokens a model can see. It is whether the work remains continuous. A user should be able to leave, return, or add a new requirement while the system still understands what it is doing.

Reliability comes from outside the model

A model completing a difficult task once does not make the product reliable.

Real environments contain waiting, timeouts, partial failures, and repeated execution. Users need to understand whether a task is still progressing, which results are already usable, and where a human decision is required. The product cannot depend on the model simply remembering to manage all of this.

An agent’s capability therefore depends not only on reasoning quality, but also on whether its surrounding system can preserve progress, constrain actions, handle failure, and return results to the decision process.

I increasingly believe that the model determines what a system can conceive, while the product system determines whether those ideas can reliably become results.

From answering questions to carrying goals

Oracle is not a set of extra controls around chat, nor a collection of tools wrapped in AI. It represents a product judgment: once AI can plan and act, the interface, state, files, and feedback must all be redesigned around how work gets completed.

Conversation remains the most natural entry point. It should not be the entire system.

The agent worth building does more than tell the user what to do next. It can receive a goal, keep advancing it, and make the process understandable, correctable, and continuous.