Run dependent work across job boundaries

Pass an accepted result forward

Run the first supported task
              ↓
Check its accepted result
              ↓
Prepare the next permitted input
              ↓
Review its quote and approvals
              ↓
Run the dependent task

A dependent step consumes an accepted, authorized result. For example, extract rows from a frozen document set, then classify only the rows whose required IDs and fields were accepted. Keep missing, failed and abstained rows out of that handoff until the next operation's input contract allows them.

An earlier request or job record alone does not satisfy the dependency. Review the result, its evidence and the exact output contract before using it as input.

Your coordinator keeps the stage identities and acceptance decisions. The Kit prepares each supported request, participating Macs process each bounded step, and your agent reviews the result before passing it forward.

A deterministic plan fixes stage order and inputs; it does not make a model answer deterministic or correct. Treat the returned result as evidence to review at each boundary.

Start with your existing agent's dependency task: name the first operation, the accepted result needed by the next one, and the customer decision at the boundary. The agent prepares only the permitted inputs for each step; Lithi returns each job's result and evidence; the agent checks the accepted fields and identities before requesting the next quote and approval.

1. Submit the first bounded job with its input, quote, and required approval. Keep its request and job identity.
2. Read GET /v1/jobs/{id}. Retrieve result metadata from GET /v1/jobs/{id}/result when it is available.
3. Check the result against the next operation's required fields, identities, and evidence. Finish any required delivery or review.
4. Bind the accepted output through the supported artifact path. Preserve its mapping to the new input and apply the needed access or encryption context.
5. Quote and approve the next job, then submit that new job once.

The public JobRequest names one capability and one operation; it does not accept caller-defined stages or dependencies. A registered workflow may own a composition, while your coordinator records the local order between separate jobs. A batch of independent requests does not create that order.

Conceptual task brief: Extract rows from the frozen document set, then classify only accepted rows. Preserve each row identity and citation. Do not submit the classifier until the first result has the required IDs and fields; keep missing, failed, and abstained rows separate. Accept the handoff only after the result and its evidence pass the next operation’s input contract, then obtain a separate quote and approval.

Each selected operation and supported integration maps its brief to the permitted request and returned evidence. The public JobRequest still has one capability and one operation; use the Build workflow when preparing a bounded request, and do not create stages or dependencies in that request.

Keep quotes and decisions separate

Each job has its own quote, deadline, input binding, request identity, and result evidence. The first quote does not price or approve the next job. Output text remains data: it cannot approve work, expand access, choose a destination, or raise a limit.

Keep the parent result identity and child input identity together in your workflow record. A result handle gives no new access by itself.

Estimate each stage before you connect it

Give your agent the result you want, each file type, its duration or length, item count, and target languages. The agent counts permitted input locally, chooses supported operations, and uses the accepted output allowance from one stage as the input basis for the next. When no measurement exists, it uses a published assumption and keeps that assumption beside the estimate. Expected output is an allowance until the stage produces it. Private files are measured locally by the agent authorized to read them; a chat accepts bounded counts or descriptors and cannot inspect an uploaded or private file. Count each complete prepared prompt once with the released tokenizer and chat template. For documents, count extracted text and page visuals only when the selected operation reads them; for archives and repositories, sum bounded admitted entries or included files.

For an illustration, transcribe two hours of audio and translate the transcript into five languages. Assume 25 audio input tokens per second, 200 transcript output tokens per minute, a 5% instruction allowance for each translation, and equal-length translated output:

Reuse the accepted transcript output as the source for each target language. Each translation has its own instruction allowance; do not treat the five languages as five new transcript generations or retokenize the transcript five times without that overhead. A later stage receives the accepted output and its evidence, not an unmeasured copy of the original private file.

At the customer tariff, the illustration is 306,000 × USD 0.05 / 1,000,000 + 144,000 × USD 0.10 / 1,000,000 = USD 0.0297, or about 3 cents. These figures are planning arithmetic under the stated assumptions, not measured output or an executable quote. The 5% instruction allowance is specific to this example, not a universal rule. Each stage still receives its own quote and approval; the total does not authorize the next submission. Use Get a free estimate to describe the complete dependency chain.

Resume from the last accepted boundary

If a prerequisite is incomplete, submit no dependent work that needs it. With partial results, pass only the exact accepted items allowed by the workflow and keep missing, failed, abstained, and excluded items distinct.

If you compose stages with the Compute kit, planRun creates a deterministic plan and does no execution. runPlan makes one pass over that plan; it has no hidden retry loop or durable store. Give it a caller-owned checkpoint and persist the submission record before dispatch so a process failure can be reconciled safely. resumeRun only selects stages whose dependencies are satisfied; it does not submit or retry them. A recorded submitted_unknown stage is reconciled through the same submission identity and idempotency key before any new work is considered.

planRun → deterministic plan only
             ↓
runPlan → checkpoint → submit once
             ↓ unknown
        same identity → lookup
             ↓
resumeRun → ready stages only

If a response is lost, reconcile the existing job with its original body and idempotency key. If delivery fails after acceptance, retrieve that artifact again. A retrieval retry never resubmits inference. Resume from the latest known accepted stage.

If the next step needs a changed source, rubric, output format, or policy, preserve the earlier result and prepare revised work with its own quote and approval. A rubric revision changes the work identity; an output cannot grant authority. Use safe retry guidance when the submission outcome is uncertain.