about

About Papayya

Papayya is ready-made infrastructure for batch and periodic AI pipelines: a task queue that grades every item, keeps the input that produced it, and lets you re-drive the one that broke.

A run of a thousand items reports that a thousand items succeeded. Thirty of them did not. They returned a value, nothing raised, nothing retried, and the exit code was zero — the answer was simply wrong. You find out from a customer two weeks later, and the smallest thing your pipeline can re-run is the whole batch.

Papayya exists for that gap. It treats the item — one ticket, one document page, one row — as the unit of execution, of verdict, and of recovery. Every item carries its own id, its own input, its own outcome and its own cost, so page 73 came back blank is a sentence the system can answer instead of a sentence you translate into a full re-run.

The distinction the product is built on

Papayya records two independent facts about every item: whether it ran and whether it worked. Durable execution engines and observability tools track the first one. Nothing in a normal stack tracks the second, because a model that returns a confident, well-formed, wrong answer raises no exception and produces no error span. Those two axes disagreeing is what Papayya surfaces.

Recovery follows from the same unit. Re-driving one item reuses the steps that already succeeded rather than recomputing them, so fixing one page of a 150-page document costs one page execution and not three hundred.

What Papayya is not

• Not an LLM gateway. You bring your own provider keys. Papayya never marks up tokens and never sits in the path of a model call in order to bill for it.
• Not an evals product. Grading here happens in production, on real items, as they run — not on a fixed test set before you ship.
• Not a tracing tool. Papayya owns the execution it reports on, which is what lets it re-drive an item. Tools that read traces from elsewhere can tell you something broke; they cannot re-run it.
• Not a framework. Your agent stays your code. The floor of adoption is a decorator on a function, not a re-architecture.

Where your data stays

Papayya does not ingest anything. An item can be an identifier — a claim number, a document key, a row id — and the first step of your agent reads the thing itself from wherever it already lives: your object store, your warehouse, your document management system, your database. Papayya never holds a credential for that source and never connects to it. Your code does, the same way it does today.

So you choose what is recorded, because you choose what the item carries and what each step returns. Send an id and Papayya stores an id, a verdict and a cost. Send the document and it stores the document — sometimes that is what you want, because it is what makes a re-drive reproduce the exact input that failed. It is a decision per workload, and it is one of the things the call is for.

Where it runs

Papayya runs in your cloud. The control plane, the worker pool that executes your code and the database that records every item are installed into infrastructure you own — one Linux host with Docker, or the Postgres you already operate. Your item inputs, your outputs and your model-provider keys stay on your machines, and model calls go straight from your workers to your provider: Papayya is never in the path of one. The Python SDK and CLI are published on PyPI and run wherever your code does. Full reference documentation is at https://docs.getpapayya.com.

Status

The SDK and CLI are public on PyPI. The server — control plane, worker pool and dashboard — installs into a customer's own infrastructure, and we are doing that with the first customers ourselves rather than publishing a download: a guided install, then their first real workload the same week. If you run batch or scheduled AI work and recognise the failure described above, book a demo. kingsley@getpapayya.com reaches a person, and the list on the home page is there if you would rather just hear when something changes.

Who builds it

We are a small team in Toronto, Canada. Papayya came out of operating a large multi-tenant LLM batch pipeline and repeatedly discovering that the expensive failures were the quiet ones — the runs that finished, reported success, and produced work that had to be redone by hand.