Durable data pipelines for coding agents
Your agent leases a small batch, submits it, and takes the next one — the pipeline's state lives on the server, not in its context, so a run outlives the session that started it. Every attempt, model and rule change lands on one ledger.
115 raw → 62 clean → 62 leased to disk → submitted → refused → attempt 2 continued the same batch from server-side state, not a new run → 62 landed · recorded with gate: on ↓
On your machine, with your model key. Tablize supplies no model and no runtime.
One leased batch, never the whole table. The rows it is not working on stay on the server, so its attention does not thin out as the table grows.
The next session resumes the run — open batches, leases, verdicts — instead of reconstructing it from a transcript.
No goldens, no gate. Supply a golden file and a check the agent cannot read judges every batch — one miss refuses the whole batch, and every refusal stays on the books.
01 / Failure mode
A model that reads fifty rows well reads row five thousand just as well — what changes is how much unrelated table it is holding while it does.
It works, and it keeps working right up to where it doesn't. Attention spreads across thousands of rows the agent is not currently deciding about, the early ones slide out of the window, and the failure is quiet — no error, no exception, just answers that drift. And when the session ends, the run ends with it.
Cheap, fast, repeatable — and the judgement that needed a model has been compressed into string matching. "Is this company a manufacturer or a trader?" becomes a regex over its name. The script is now the only statement of the rule, nobody reviewed it, and the rows it got wrong look exactly like the rows it got right.
Your agent asks for the next batch, computes it, submits it, asks for another: the model still does the semantic work, but it only ever holds the rows it was handed. And because your agent does the computing, a flat-rate coding-agent subscription does the work a per-token API bill would have.
The choice was never model versus script. It is whether the process lives in a context window that forgets, or in a structure that doesn't.
02 / Why an account
This is about a run whose referee, whose state, and whose reasons all live inside the worker.
The agent writes the extraction logic in this session. When a row looks wrong, the same agent adjusts the validator — and the batch passes. Nothing prevented that, because nothing was outside the agent.
Which rows were leased, which came back, which were rejected and why — all of it lived in a transcript. A new session sees files and partial output, and rebuilds the run from clues instead of resuming it.
Which rule version accepted this row? Which model produced it? Was it ever rejected first? If the answer is "check the chat history", there is no account — there is a recollection.
If the worker can rewrite the referee, you don't have a gate. You have another prompt.
03 / The governed edge
Tablize governs four steps and refuses to claim the rest. The bottom line of each box says whether that step is yours or ours.
Append-only source rows — a crawl, an export, a hand-assembled CSV. Duplicates are kept: they are a fact about collection, not an error.
Collected by you or your agent · Tablize does not fetch it
Your agent leases a bounded batch to disk, runs your prompt against your model, and submits the results as one batch with the model and prompt hash attached.
Runs on your machine, your model key · Tablize supplies no model
Build the line without goldens and there is no gate: nothing is judged and rows land unverified. Supply them and check rows with known answers ride in every batch — expected values held server-side, never returned by a lease, one miss refuses the whole batch.
Held by Tablize once the line has goldens · the submitting agent can never read or approve them
Not a fourth table — a reading of the process table showing the latest row per source row. With the gate on it shows accepted rows only and refused attempts move nothing; with the gate off it shows what landed, marked unverified.
Projected by Tablize · you decide whether anyone downstream uses it
The one thing that has no CLI command: on a gated edge, when your agent writes the check rows itself, the line is created as a draft and hands out no work until a person opens the gate in the app. That is the 403 · pending_signoff in the replay above. An agent that could approve its own answer key has not been checked by anyone. An ungated edge never reaches that question: it hands out work immediately and marks what lands unverified.
04 / The gate you tighten
Nobody, until you write the check. There is no switch to leave off: a gate built on goldens you were not ready to write is a noise gate — and a noise gate is worse than none. The mode is fixed when the line is built, so tightening means rebuilding it: a deliberate step, taken when the pipeline is worth protecting. The results the old line already produced stay where they are.
Everything is still accounted for: every batch, model, standard version and timestamp is on the record. What is missing is the check — nothing compares the results to an answer a person confirmed, so they arrive unverified. This is the right first run and the wrong last one.
Every batch is compared to the goldens and the score is recorded, but no batch is ever stopped, so results still arrive unverified — even a clean sweep. When the gate cannot hold, a pass is a measurement, not a certification. Use the scores to decide whether these goldens are the right ones before you let them block anything.
Goldens are hidden and binding. A failing spot-check rejects the whole batch, and consecutive rejections halt the edge rather than letting it grind. Only enforce can grant "accepted" — which is the entire reason that word is still worth something.
The gate is the first thing on the ledger you can tighten. It is not what makes the pipeline durable — that part is already running with the gate off.
05 / Product evidence
The same run, in the application, recorded with the gate on (enforce) — that is what makes a refusal visible at all. Unretouched, at 100% zoom, cropped only where each header says so.
The whole edge on one canvas: 115 raw rows, 53 folded away by url, 62 clean rows, the extraction, and the gate.
The label on the edge leaving the gate is the product's own, not a caption we wrote: 62 through · 62 blocked writes. Recorded but not promoted, drawn on the line itself.
One row carries the whole account of a batch: its id, how many rows it leased, the hidden check score, the model that produced it, and how many times it was submitted.
The status strip lists rejected 62 beside accepted 62. Rejection is a first-class state here, not an error log to be cleared.
Filter to rejected and the 62 refused rows are still there — the company, the category the model chose, and the evidence text it was judged on.
That is what makes the next attempt arguable instead of guesswork: you can read what the weaker model actually said before you decide what to change.
Screenshots come from a local instance on 2026-07-28. The mechanism, ids, counts, verdicts and system columns are the product's own state; the supplier rows are sample data generated for that run. Shots B and C were captured in the product's light theme and are shown that way in both site themes — we would rather label a screenshot than retouch one. There are no customer logos on this page because there is nothing to show yet.
06 / Is it for me?
One agent, one afternoon, cheap to be wrong — a CSV is the right answer and this is overhead. Check what is actually true of your workflow.
0of 10
Not yet answered
Check the statements that describe your workflow. The result is a recommendation, and one of the three is "don't use this".
Next step — read the boundary below before you install anything.
07 / Honest boundary
The most load-bearing section on this page. An account that overstates its own scope is worse than no account, because people stop checking the part it never covered.
A row marked accepted passed the rules and check rows as they existed at that moment, and the version is recorded. A row marked unverified was never judged — the label tells you which you have.
Every attempt, batch, model and rule change is accounted for — who, when, under which recipe version.
Failed attempts are kept and readable, and they never enter the accepted view. With the gate off there are no refusals to keep — nothing is judged, so nothing is refused.
The next run continues from server-side state — open batches, leases, verdicts — with no transcript required.
That the source data is true or complete. Evidence a row never carried cannot be recovered at the gate.
That the fields you defined are the fields downstream actually needs. Tablize enforces your contract; it does not discover it.
That anyone used the accepted result. In our own first end-to-end tenant, 128 of 136 accepted rows were never picked up by anything downstream — five rounds, unnoticed, while the ledger stayed accurate the whole time.
That your agent writes nothing outside Tablize. It has your machine and your keys; this account covers one edge, not the agent.
08 / How it works
Four commands. No account form, no dashboard tour, and no long-lived key pasted into a terminal.
$ npm i -g @tablize/cli $ tablize install $ tablize login --url https://api.tablize.com $ tablize doctor
Set up Tablize as the durable pipeline for this project's clean → extract → accept work. The point is that the process state lives on the server, not in your context. 1. Run `npm i -g @tablize/cli`, then `tablize install` to lay down the bundled agent skill. 2. Run `tablize login --url https://api.tablize.com` and ask me to approve the browser pairing. 3. Run `tablize doctor` and fix any version, skill, server, or workspace mismatch. 4. Inspect this project and propose the raw evidence contract and the extraction result schema before creating a pipeline. 5. For the first run, create the extraction edge with no golden file — it runs at `none`: nothing judged, rows land unverified. Do not invent goldens just to fill a field. 6. Work in small batches: `batch pull`, compute, `batch submit`, repeat. Never load the whole table into your context, and resume from `tablize context` rather than from this conversation. 7. Read `gateMode` from `tablize transform show` before you trust a row: only `enforce` marks a row accepted. The gate is fixed when the line is built, so moving to `observe` or `enforce` means building a new line — propose it when the pipeline is worth protecting, and ask me first, because I sign the goldens, not you. 8. Never rebuild a line at `none` to escape goldens it keeps failing. That is the gate doing its job. 9. Keep collection completeness and downstream consumption explicitly outside Tablize's guarantee.
Why pairing rather than an API key field: the commands here are driven by agents as often as by people, and an agent has no browser and no password. Pairing gets it a working credential with one human click — and the secret never appears in a web page, a clipboard, or your shell history.
What actually happens · real CLI and browser output
🔐 Sign in to tablize Opening: https://app.tablize.com/cli-login?code=… Confirm this code matches: BFTK-9QDX Waiting for approval....
Nothing is granted yet. The request expires on its own if nobody approves it.
Sign in to tablize? A command-line client is asking to connect to your account. Client tablize CLI · your-mac · you Code BFTK-9QDX What it will be able to do Read and write your data. It cannot manage members, policies or billing, and it does not expire — revoke it any time in Profile → API keys. [ Approve ] [ Refuse ]
You compare the code against your own terminal before approving. Refuse grants nothing and tells the waiting terminal to stop.
$ tablize doctor
{
"summary": { "ok": 9, "warn": 0, "fail": 0 },
"message": "all three layers healthy against
https://api.tablize.com (9 ok, 0 warn) —
this verdict covers that server only",
"next": "tablize context # open tasks, recipes, rules"
}
Installed == running? Skill == CLI? Server capabilities online? Any failing check comes back with the exact fix command attached, so the agent can repair it without asking you.
09 / Pricing — one base, tier = rung
Same engine on every tier. You only move up a rung when your workload does.
$0
Shared server, quota-capped
Usage-based
Pay only for what runs
Self-host
Always-on · private
Public beta · free · macOS, Linux and Windows