Use the Compute Kit with your agent

Read the smallest useful bundle. Begin with public documentation to assess fit. If an authorized Kit copy is supplied, read the universal Compute skill, add only the workflow and privacy guidance for the task, then inspect the exact helper or example that answers the next question.

The Compute Kit is software on your computer, in the environment you control. Your existing supported AI agent uses it to prepare permitted data, encrypt it into blocks before transfer, get a quote, submit approved work and review the results. The agent keeps its own model, context, planning, edits, builds, tests and final decisions. Skills explain the process; they do not train model weights, grant account access, approve a transfer or authorize paid execution. Once the Kit and your approved account are connected, your supported agent can handle these technical steps within your approval. You choose the work and approve what may be sent and spent.

One public assessment path

Use the public reading guide to choose the source for your question. The paper explains the architecture. Availability and access explain the account and operation checks; the Work API reference supplies exact request and response contracts.

Use https://lithi.ai/api/public/compute/assessment when it returns assessment.kit_review with mode: documentation_only and review_mode: read_only. The admitted object identifies the public overview, contents, review, agent guide and interface reference with a human url, Markdown markdown_url and source_version.

Read the Markdown when an agent needs headings, tables, limits and links. Read the human URL when a person needs the rendered page. If the endpoint is unavailable, use the canonical public pages that are already accessible and label freshness and availability as conditional. Do not fetch raw Kit source, a release archive or a signature, install the Kit or run an example during this assessment.

The public path answers whether the work is bounded, whether the data boundary fits and which next guide to read. A browser review is read-only; it is not an HTTP or MCP integration.

For returned work, read result files and verification. For a lost response or failed attempt, use idempotency and safe retries before submitting anything again.

One supplied-Kit path

After a Kit is separately supplied and authorized, follow this sequence:

1. Read .agents/skills/lithi-compute/SKILL.md for fit, preparation, quote, approval, execution, results and recovery.
2. Choose the matching domain skill, or an optional privacy companion, from the task table below.
3. Read docs/WORKLOAD_FIT.md and the relevant public boundary guide before selecting the input, output and checks.
4. Use docs/FILE_INDEX.md or catalog/kit-index.json to locate the exact helper, interface or example. Read only that path and its caller or test when a behavior needs checking.
5. Prepare the smallest permitted input locally, request a quote, obtain transfer permission and approve the exact quote or bounded policy before submitting work.
6. Reconcile the returned identity, verify the declared result and apply accepted changes locally.
7. If your account permits reporting, read an authorized monthly report through the reporting API with reporting:read, or use an approved report file. Reporting is separate from Work tools.

Your agent can identify suitable tasks, prepare requests, request quotes and run work after you connect an approved account. Transfer permission and approval of the exact quote or bounded policy still govern those actions. The agent asks before an action exceeds those limits. A skill or public page never supplies that authority.

The five work tools are exactly lithi.quote, lithi.run, lithi.batch, lithi.status and lithi.result. MCP-capable agents use MCP where the selected host supports it; applications can use REST or a supported SDK. A compatible agent needs one of those supported transports and approved account access. A chat interface does not automatically gain local file access or Compute connection support. Reporting uses its separate reporting:read API or an approved report file; it is not a sixth Work tool.

Select the task bundle

Use the first path as the entrypoint. Open later paths only to answer the question that remains.

The task bundles are a starting point, not a complete tour. Do not load every skill or example when a single path answers the question.

For a coding task, give the agent a fixed permitted diff, its callers and types, the relevant schema or interface, existing test evidence and the review rubric. Lithi can return bounded, source-linked findings or reviewable suggestions. Your coding agent remains responsible for repository edits, native builds, tests and the final acceptance decision.

Match a skill to the task

All twelve skills live beside the universal skill in an assembled Kit:

The eight workflow guides are Lithi Text & Data (llm-agent-work), Lithi Audio & Video (creator-media), Lithi Code & Tests (code-review-testing), Lithi Data & Evaluation (data-evaluation), Lithi Documents & Search (documents-retrieval), Lithi Translation (translation-localization), Lithi Apple ML (apple-ml) and Lithi Image Analysis (vision). Vision has no separate domain skill.

Keep the host boundary visible

The agent's workspace is where its process runs. A cloud-hosted agent may be unable to read local records, an alias key or a result destination. Local preparation, sealing, key custody and restoration happen only where the selected integration supplies them. With managed custody, Lithi's key service could technically decrypt input. With customer-held custody, the local Kit releases keys and stays online while work runs. An executing Mac reads the plaintext of its granted piece; a privileged owner may inspect that plaintext, so encryption does not make the device confidential.

Many Macs may handle admitted bounded work when placement permits it. That does not guarantee capacity, speed or a deadline, and the customer does not choose Macs, shard sizes or retry topology. The service owns placement and execution within the approved scope.

Follow one example end to end

For a fictional support-ticket classification task, use this single path after the public review:

Assess the task and prepare permitted input locally
               ↓
Connect an approved account and interface
               ↓
Review the quote, transfer permission and execution approval
               ↓
Run; read status and result
               ↓
Check coverage, integrity and task quality
               ↓
Continue your work or save to the permitted destination
               ↓
Interpret an authorized monthly report when reporting is permitted

examples/typescript/src/full-journey.ts is a synthetic module-composition tour. A fixture transport in examples/typescript/src/real-sdk-journey.ts exercises the SDK contract. Neither proves live execution or semantic quality. For exact method signatures, helper effects, refusals and result levels, use the interface reference.

Read an authorized monthly report

The report can distinguish accepted_work_macs, physical_activity_macs and provider_accounts. These are different populations, not additive totals. Read the availability labels beside each figure before describing what the report establishes. The report explains recorded work and participation; it does not turn a provider-account count into a people count. Allocation remains separate from confirmed payment, and measured or estimated energy remains separate from claimed savings.

Use the Compute impact report for the reader explanation and the Compute Impact Reports API for exact fields. A report file approved for your account can provide the same authorized input when API access is not the selected path.