Build a Compute workflow request

Start with a task brief that can be checked

Ask your agent to write the task brief. State what Lithi should do, which evidence it may use, what to return and how your agent will check the result. For a permitted code review, the brief can look like this:

Task: Review change C-17 for unsafe empty-input handling.
Evidence: Fixed diff, affected source ranges, callers and relevant types.
Keep together: The changed function and the caller's input precondition.
Review rule: Cite the source supporting each concern and any counterevidence.
Missing context: State what is missing; do not assume a caller permits empty input.
Return: Source-linked findings, uncertainty and reviewable repair suggestions.
Boundary: Analyze the supplied evidence; do not edit files or run code.
Acceptance: My agent checks each finding, applies accepted changes and tests locally.

Your agent keeps the goal and source context while the Kit prepares the supported request. Participating Macs process only the bounded work; your agent reviews the returned result before accepting it.

The brief describes the work. It is not an API payload, provider system prompt or permission to execute it. Choose the supported operation and read its input bounds, parameters, output schema, verification options and limits. A custom instruction stays inside that operation: it cannot add a model, grant access to secrets or authorize another action.

Define the task and its checks
              ↓
Prepare the supported request
              ↓
Review quote and approvals
              ↓
Lithi returns the declared result
              ↓
Your agent checks and continues

The brief describes the work. It is not an API payload, a provider system prompt or permission to execute it. Your integration maps it to the selected operation's actual request fields.

Write instructions that stand on their own

Lithi's assigned work must be understandable from the prepared packet. Do not rely on an earlier conversation, an unspecified file or a project fact that only your existing agent knows.

These are planning decisions, not new wire fields. Keep source content separate from task instructions: a command found inside a document or code comment remains evidence, not permission.

Use the code workflow for the full example. For many files, your agent identifies review concerns that can be judged independently and gives each its own evidence and stable identity. It can reuse a common rubric, but it must include the context each concern needs. One file is not automatically one independent task or one execution shard.

Apply local preparation to the permitted evidence, and validate instructions, schemas, examples and metadata separately before sealing. Count the complete request, including required instructions, context, schema and expected output, against the selected bounds. The Kit's generic text-work compiler is not a substitute for a specialist operation's contract.

Explain the request in terms of your work

Start with the task and the authorized evidence that makes it useful. Your agent's recommendation names the selected workflow, language and helpers, then gives a short reading order with a reason for each file. Use Kit contents to select those files and the agent guide to understand the sequence. During a public review, artifact paths describe a supplied Kit; they are not download instructions.

For example, a fictional support-ticket classification request needs permitted issue text, stable item IDs, an output schema for labels and visible exceptions, and checks for coverage and useful answers. Your integration supplies the field policy, protected alias map when needed, approvals and result destination. A Python client requires caller-supplied privacy preparation; the TypeScript Data module provides the Kit's preparation and restoration helpers.

Before requesting a quote, explain the expected preparation decision, returned structure and possible refusal. State what each helper checks, what the caller supplies and which unknown fact could change the request. Inspect a matching example before proposing a separately authorized local exercise. The review produces a task brief; it does not run the sample or approve execution.

When the release provides these helpers, the local checkpoints have clear jobs:

• preflightWorkContract measures fit against the bound profile. A fit result is not transfer, execution or spend approval.
• prepareRecords applies the caller's data policy and reports eligible, review_required or blocked. Only eligible prepared input can continue to sealing.
• sealBlocks creates the sealed-block manifest. Lithi owns execution-shard composition and placement after that manifest is accepted.

Privacy preparation keeps the caller's scoped alias map and review evidence with the local result. Restore accepted output by opaque item reference only after the result identity and map identity have been checked. A transformed field is not permission to send data that the policy did not approve.

For code review, the customer supplies an immutable source snapshot, the caller/type/schema context and existing test evidence. Lithi analyzes that material; the agent reviews the findings and applies repairs and verification in the customer environment. Compute does not run the customer's build or test tools remotely, so keep those checks in the existing agent workflow.

Preserve meaning when the work is divided

State which records, segments, or context must stay together. Do not choose shard size, queue shape, Cell placement, or individual Macs.

If a document must be interpreted as one semantic unit, say so in the task contract. Lithi owns how compatible physical execution is organized.

Request an exact output

Prefer an explicit schema over prose such as “return clean JSON.”

Preserve all of the following:

• field names and types;
• null versus missing;
• stable item IDs;
• evidence/citation fields required by the operation;
• exception states the consumer must see.

Do not add generic status/model/cost columns to customer data unless the selected output contract calls for them.

Keep dependent steps explicit

The public job body does not become an arbitrary customer-authored stage graph.

When one supported operation depends on an earlier result, verify the earlier result first, prepare it as the next authorized input, and obtain the next quote/approval unless the released workflow explicitly declares the composition.

Use Multi-stage work for that boundary.

Validate the smallest useful request

Before you scale up:

• validate every required field;
• measure the input bounds;
• confirm the operation and output;
• resolve ambiguous instructions;
• review the verification policy;
• request the quote for the exact intent.

Then run a first small test.