A Workflow is a small ordinary Python project in its own Git repository. It uses the existing Agent method, calls other projects through normal imports, and combines goal(), agent() and llm() as the task requires. The detailed design is organized into three topic pages.
The system manages multiple reusable Workflows. A Workflow can call another Workflow or directly call ordinary Functions, single model requests, Agent loops and Goal loops. Callers should not learn another API, and generated code should not pass string names to an additional dispatcher.
Out of scope: Workflow DSLs, custom revision databases, remote Marketplaces, automatic push, background distributed scheduling and new model-tool protocols.
| Current facts | Remaining differences | Target page |
|---|---|---|
Agent method Python calls, tool registration, Runtime inheritance and the DAG are supported. | An earlier design redundantly added @workflow and a call adaptation layer; these have been removed from the target design. | Programming model |
| Discovery, creation, revision and user-triggered automatic execution are four registered functions; the former composite entry is no longer registered. | workflow/ Category directories still need to be fully separated from Programs execution identity, followed by default-App acceptance. | Discovery, creation and automatic execution |
openprogram/programs/workflow/ is already the source of truth. | Programs does not yet display Exports, Calls / Used by, Git or test status. | DAG and Web UI |
@workflow, call_workflow(), invoke_workflow(), Function sidecars and a public resolver/executor are outside the target architecture.Abstractions, llm/agent/goal, project directories, cross-Workflow imports and execution snapshots.
Open topic →Document 2Public search/create/revise contracts, user-level auto entry, component reuse, lifecycle, migration and acceptance.
Open topic →Document 3Runtime parent-child relationships, static Calls / Used by, complete Programs prototype and interaction contracts.
Open topic →| Reference | Adopted | Not adopted |
|---|---|---|
| Python import system / contextvars | Standard packages/imports and inheritance of the existing call context. | Custom import hooks and string dispatchers. |
| Git commits / git worktree | Project history, commit snapshots and isolated changes. | Revision directories and active pointers. |
| GitHub reusable workflows | Independent reusable units, explicit inputs and composed calls. | YAML Workflow DSL. |
Existing OpenProgram Agent method | Tool registration, DAG, Runtime, permissions, cancellation and provider/model inheritance. | A parallel registration system. |
| Capability | Status | Details |
|---|---|---|
| Parameterized entry points, multi-file packages and independent Git repositories | Stages 1–3 complete | New projects use the same name as the project for method_options = dict(task). |
| Static cross-Workflow imports and reachable commit snapshots | Stage 4 complete | Implementation evidence exists for missing/cyclic dependency rejection, dependency snapshots and shared Runtime. |
| Legacy zero-argument single-file Workflow | Resume compatibility only | Used only by historical runs explicitly resumed. |
| Single-Agent authoring | Design complete · not implemented | Remove decision JSON and the separate author turn. |
| Executable test gate before publication | Design complete · not implemented | Failures, timeouts or cancellation must not produce a commit. |
| Programs → Applications | Design complete · not implemented | Workflow is an Application source type; do not add a separate peer Workflows category. |
Canonical design set entry. Implemented evidence through Phase 4 remains distinct from the three approved targets without implementation evidence.
llm_knowledge_research makes one bounded planning call through the existing llm primitive before official arXiv retrieval. Its strict plan contains one to four ordered queries of at most 256 characters, with a supported theme, and respects the requested priorities and exclusions. The planner supplies retrieval intent only; it cannot supply evidence, dates, paths or paper results. Invalid plans fail before HTTP or output writes and do not trigger validation retries or a fixed-topic fallback. Retrieval retains at most four calls with 25 results each, the existing 2025/2026 publication filter, deduplication, provenance and five selected records per included theme. The report renders only planned themes and actual normalized abstracts; excluded-theme stock text is omitted. One Asia/Shanghai acquisition date is captured at invocation start and passed unchanged to the report. A standalone rendering call without acquisition metadata labels its current render date separately. No-result, planning, transport, cancellation and write failures retain the existing failure and output-preservation behavior. Public acceptance invokes the registered workflow with distinct broad and narrow requests, checks actual query receipts and persisted scope/date, and proves invalid plans perform no retrieval or write. Real model planning quality remains a separate acceptance check.
The plan explicitly permits the existing prompt fallback when a configured provider has no verified native or strict-tool structured-output contract. Schema validation and zero validation retries still apply; this does not introduce another model request, a repaired plan or a fixed query set. Acceptance reaches the production structured-output negotiation boundary for such a provider, then validates its single returned plan before any source request. A malformed response remains a typed failure with no retrieval or report write. Live provider and remote retrieval results are recorded separately from controlled acceptance.