Create a task

The creation form collects only what it must

Creating a task uses at most two or three main steps. The default form collects requirement sources, a task name, the repository and the base branch. Inputs specific to a flow appear only when you explicitly choose to use that flow.

Model, knowledge, capability and orchestration details are not required configuration for an ordinary user. That is deliberate: having to understand the whole domain model should not be the price of getting started.

Requirement sources

A source is multi-line, and the lines together compose one requirement.

Every line uses the same two-segment interaction. The selector in the first segment only switches that line's type — choosing a source never fires a file picker or any other side effect. The second segment expands the input panel for that line alone.

The Markdown panel opens on an empty file-upload state and, once read, collapses to the filename, size, character count and a replace or remove action. The body is kept as a frozen payload and is not expanded into an editable block of text by default, because the requirement is an input to be reproduced, not a document to be rewritten in place.

An online source panel — Git issue, enterprise document, enterprise instant messaging — shows a single link input carrying the semantics of its source, plus a clear action.

Re-selecting the source a line already uses keeps the input it holds; only switching the line's type clears that line. Adding, deleting or reordering other source lines never corrupts the content of this one.

Which sources are visible is decided by the deployment rather than by a static fixture guessing at a company's tool stack. Markdown and Git issues are built-in sources the control plane always returns; enterprise documents and enterprise instant messaging are enabled explicitly by deployment configuration and exposed to the interface through an availability API.

One caveat matters here. The availability contract proves only that the entry point is enabled. Until the connector that fetches external bodies ships, the task context still freezes the source address and the platform-generated metadata, and does not pretend the body has been downloaded.

Task name

The name field arrives with an editable default, which saves retyping. It picks the first available title in source-line order:

• Markdown — the first level-one heading that is not inside a code fence, falling back to the filename when there is none;
• Git issue — the real title, read through a connector the current user has already authorised; if that read fails, the placeholder is kept and creation continues.

The automatic value follows source replacements and asynchronous results only while the name has not been edited by hand. Once a user has entered a non-empty name, later source changes must not overwrite it. A non-empty name restored from rebuilding an original task or from a browser draft is treated as a confirmed manual value.

The name carries resource identification and acts as a list title, nothing more. The task requirement held in the task context is what the agent actually executes against.

Repository and branch

The creation page does not accept a free-form repository address. The control plane works in this order:

1. Git services for which the current user has configured a personal token become the selectable services;
2. the server decrypts the current token and queries the repositories it can reach, live;
3. once a repository is chosen, branches are queried, with the provider's default branch suggested first.

Switching Git service or repository clears the downstream selections. A rejected token, a network failure and an empty repository each produce their own recoverable state.

The point of that order is that token problems surface before execution does. If a token is invalid or lacks permission on the repository, the task fails during preflight rather than halfway through a run.

Issue titles are read the same way: only server-side, using the current user's credentials, and only after validating that the link matches the address and path contract of a configured connector. The browser never talks to the provider API directly. The interface returns the connector identifier, provider, repository full name, clone and web addresses, default branch, private flag, branch names and protection flags, plus the issue's repository, number, title, web address and state — and nothing else. Access tokens, ciphertext and key references never cross out of the control plane.

Flow modes

Smart orchestration is the default. After a task is submitted, preflight retrieves, evaluates and prefers to reuse an existing published version, generating a task-scoped temporary flow only when nothing fits.

The actual order on that path is: analyse the task goal, the supplied requirement, the constraints, deliverables and acceptance criteria; search the published flows visible to the current user against that requirement; for each candidate, read the complete contract of the exact version and compare inputs, outputs, nodes, dependencies and capabilities; reuse the exact version when one satisfies the task, and generate a new flow only when none does.

A directory read or a tool call that fails does not mean there is no suitable flow. The system must not hide the fault and then claim a match was found.

Use an existing flow lets the user pick a published version visible in the current workspace scope through a compact selector. Selecting one expands only the fields of that version's input contract that cannot be derived.

Create a flow moves to a separate authoring page. Editing a long-lived asset does not belong inside the task form.

Models and capabilities

The creation page offers no task-level model selection. The model is fixed in each node's capability definition, and task creation freezes the exact version.

Knowledge access is handled by the control plane, which issues a minimal delegation scoped to the task principal, the Organization and the workspace, and force-injects the system knowledge recall skill. A user does not choose or need to understand knowledge when creating a task.

Triage order when preflight fails

A failed preflight leaves the task with structured check results. Working through them in this order is usually fastest:

1. Personal token — is one configured, has it expired, does it have permission on this repository;
2. Repository and branch — does the branch still exist, is the default branch restricted by a protection rule;
3. Capability visibility — are the skills or extensions the chosen flow declares available in your current workspace;
4. Model gateway — is the gateway reachable, is the selected model on the catalogue;
5. Flow contract — if you are using an existing flow, are all its required input fields filled.

A failure creates no run resources at all, so resubmitting after a fix leaves nothing behind to clean up.