Let your AI agent run a batch and read typed results

What you get

A batch your agent submitted, and results your agent can act on without reading prose.

• One typed row per item in data/part-*, carrying lithi_result, lithi_confidence and lithi_evidence.
• A typed status per item in lithi_status, so a refusal is never mistaken for a label.
• Anything the workflow declined to label in abstentions/part-*, with a reason and a next action.
• metrics.json and receipt.json, so your agent can reconcile what it asked for against what it was charged for.

Every result carries evidence. A label your agent cannot trace back to the text it came from is not usable, however confident it looks.

What you need

Twenty synthetic items and a declared label set. Synthetic matters here, because you are testing the loop rather than the data.

request_id,channel,language,text
REQ-2001,web_form,en,Card was charged twice on the same order.
REQ-2002,web_form,en,How do I add a second workspace member?
REQ-2003,chat,es,Necesito cancelar antes de la renovacion.
REQ-2004,chat,en,,
REQ-2005,web_form,en,Please export everything you hold about me.

Declare request_id as your item_id_field, and declare your labels as a closed list with types. Row four is empty, so it should be refused at validation rather than labeled. Row five should land in the label you use for a rights request, which is the one you least want quietly mislabeled.

Your agent also needs a work key. A work key holds work scopes only. It can quote, submit and read results. It can never invite a member, register a destination or touch finance.

Run it

1. Have the agent shape the request. lithi.plan() and lithi.recommend() are local helpers: they compare workflows and draft parameters, and they neither quote, admit nor run paid work.
2. Have the agent quote with lithi.quote. The quote carries a maximum charge, an expiry and a signature, and it authorizes nothing at all.
3. Read the quote yourself and approve it. Approval is a separate act by a person or a signed policy, and it is the only thing that lets paid work start.
4. Submit with lithi.batch for the collection, or lithi.run for a single item.
5. Poll lithi.status until the job is terminal, then fetch with lithi.result.

Those five tools are the entire work surface your agent gets. There is no sixth, and no management action hides inside them: how work keys and management stay separate.

Read the result

Open result-manifest.json before reading a single row. Part files can exist while a job is still running, so their presence never means the work finished.

Then have the agent branch on lithi_status, not on the text of lithi_result. A label, a refusal and an abstention are different outcomes, and every non-success carries a safe reason and a concrete next action to take.

Read three things by hand on this first run. Check that the empty row was refused with a typed code. Check that the rights request got the right label. Then open the cited evidence for the five lowest-confidence rows and confirm the text supports the label.

If the job returns REPLAN_REQUIRED, the world moved between the quote and admission. Have the agent quote again rather than retrying the old submission: what a quote does and does not authorize.

Where it stops

Your agent gets typed results. It does not get authority.

Nothing is sent, published, filed or written back. No reply goes out, no ticket is updated, and no record in your own systems changes because a label arrived. The agent proposes; you decide.

The approval gate stays with you even when the agent runs unattended. A quote is a price, not permission, and an unapproved quote simply expires. Set a spend ceiling so an agent loop cannot approve its way past what you intended.

No accuracy is promised. Confidence is a measurement, and the label set is yours, so a wrong label usually means the label list needs a clearer boundary. A person reviews the low-confidence rows and the abstentions before any of this touches a real collection.