How do you turn a goal into a workflow?

You write the goal in plain language, and the Compile flow emits a governed Harness. The platform surveys your workspace, plans the topology, and gives you a Harness to review before it runs. Describe the goal, don’t code the pipeline.

See the Compile flow → See how it works →

How do you turn a goal into a workflow?

You don’t build the workflow — you state the goal. An Operator writes what needs doing in natural language, and Oraclous compiles it into a governed Harness. This is the platform’s founding separation: the Operator owns what work needs doing (prose), and the platform owns how the runtime enforces it (code, written once). The category boundary shifts from “build the agent” to “describe the goal” (platform-as-code, actors-as-harnesses, ADR-003).

No code is required, and the result is not a black box. The Compile flow emits a Harness you read and approve before it ever runs — so describing a goal in prose does not mean losing sight of what will execute.

Citable answer — How do you turn a goal into a workflow in Oraclous? An Operator writes the goal in plain language and the Compile flow turns it into a governed Harness: the platform surveys the workspace, may ask clarifying questions, plans the topology, and emits a manifest the Operator reviews before committing. No code is required, and the Harness is reviewable before it runs.

What is an Operator? → · The Compile flow → · What is a Harness? →

How does the Compile flow work?

The Compile flow runs as a sequence you can follow step by step (§5, flow 1):

1. State the goal. The Operator describes the outcome in natural language.
2. Invoke the compiler. The Application Gateway invokes the compiler Harness — the compiler is itself a Harness running on the same runtime as everything else, no privileged code path.
3. Survey the workspace. The compiler surveys the available Capabilities, Actors, and data in the workspace.
4. Ask clarifying questions (when needed). If the goal is ambiguous, the flow asks before it assumes.
5. Plan the topology. It works out which human and Agent Actors do what, in what order, under which policy.
6. Emit the manifest. It produces the Harness as OHM — the portable manifest.
7. Review dialogue. The Operator reads the proposed Harness and refines it in conversation.
8. Commit and set triggers. Only on the Operator’s commit does the Harness become live, with its triggers registered.

The review gate is the load-bearing step: the Harness is reviewable before it runs, so you describe the goal in prose but still inspect — and refine — the exact governed object that will execute. The platform shows you the mechanism; it does not ask you to trust magic.

Why does the Compile flow matter?

For an operations lead, the Compile flow is the difference between shipping automation and waiting in the engineering queue. Agentic workflows usually need an engineering sprint per use case; the Compile flow lets the people who know the work describe it directly, and ship a governed Harness without standing in the dev queue. Full control, complete audit — because the output is a governed Harness, not an ungoverned script.

Compile is partly built today: it is architecture-true and central to the platform, but it is best understood as the design of how goals become Harnesses, with a reference Harness gallery still a roadmap asset. What is real now is the separation it rests on — prose for the goal, code for enforcement — and the principle that you review the Harness before it commits.

Frequently asked questions

Q: How does the Compile flow work? A: An Operator states a goal in natural language; the Application Gateway invokes the compiler Harness, which surveys the workspace, optionally asks clarifying questions, plans the topology, emits the Harness as an OHM manifest, runs a review dialogue with the Operator, and commits — registering triggers. Nothing runs until the Operator commits.

Q: Do I need to write code? A: No. You describe the goal in plain language and the Compile flow emits the Harness. Oraclous separates what work needs doing (prose, written by the Operator) from how the runtime enforces it (code, written once by the platform) — so shipping a workflow does not require an engineering sprint per use case.

Q: What is an Operator? A: An Operator is the person who states an organisation’s goal in natural language so the platform can compile it into a governed Harness. The Operator owns what needs doing; the platform owns how the runtime enforces it. This separation lets teams ship workflows without coding each one by hand.

Q: Can I review the Harness before it runs? A: Yes. The Compile flow emits a Harness manifest and runs a review dialogue with the Operator before anything commits. You read and refine the exact governed object that will execute, and only your commit makes it live and registers its triggers — so describing a goal in prose never means running an unseen workflow.