AI workers for Records

What is an AI worker for Records?

Records is the data store your workers keep between runs: named collections of rows, shared across your workspace or private to one worker, that the owner can see and edit at any time. It is what turns a set of separate workers into a team: the worker that finds opportunities writes them down, the worker that does outreach picks them up, the worker that reports counts what happened - all from the same collection, with every row carrying who wrote it and from which run. There is nothing to connect and nothing billed; the store is part of the platform.

What these workers do

Run a prospect pipeline across workers

A finder writes candidates with a status of new, an outreach worker picks up the new ones and marks them contacted, and a reporter counts what moved - one collection, three workers, no duplicates.

Keep a monitor from repeating itself

A private ledger keyed by the thing being watched, checked before anything is reported, so a daily run stays quiet about what it already said.

Maintain a roster the whole team reads

Client domains, store locations or accounts as one shared list the owner edits on the dashboard and every portfolio worker iterates on its schedule.

Hand context between jobs

What one worker found this morning becomes the input another reads this afternoon, without a document to open or a message to parse.

Give the owner a table instead of a report

The work queue lives as rows with statuses rather than as a digest to read, so it can be sorted, filtered and exported like any other table.

How an AI worker runs in Records

Rows are data, not memory

Shared or private, decided per collection

Keys make re-runs safe

Some values are refused on purpose

The owner sees everything

Records questions, answered.

Do we need to connect a database or a spreadsheet?

No. Records is part of the platform, so a worker with it switched on can create a collection and start writing rows on its first run, and there is nothing to authorise or configure. If you would rather keep a pipeline in a sheet or a board you already use, workers can do that too; Records is for the state that has no better home, and for the cases where several workers need to read and write the same rows without a shared document in the way.

Can any worker read any collection?

A worker with Records switched on can read and write the shared collections in your workspace and its own private ones, and nothing else: another worker's private collection is invisible to it, not merely forbidden. Which of the four operations a worker may perform - read, write, delete, create - is set per worker, so a report worker can be read-only while a finder writes. Finer, per-collection bindings are on the roadmap.

How much can a collection hold?

Up to twenty thousand rows of four kilobytes each, with fifty collections per workspace, and a worker writes or deletes up to a hundred rows per call. Those limits are meant to keep the store a working set rather than an archive: long material belongs in a document or a skill resource, with the row holding a reference to it.

What happens to a value that looks sensitive?

It is refused. Records screens every value on the way in with the same detectors the always-on data scan uses, and a credential, a card number or a government or financial identifier is never stored, whatever the worker intended. The refusal is reported per row so the worker knows, and the rest of the batch is written normally.

Can the owner change what a worker wrote?

Yes, on the Records screen: every collection is a table the owner can browse, edit row by row, import into and export from. A row edited there shows no writing worker, which is how a worker can tell a human's correction from another worker's claim.

What AI workers can do in Records

The tools a worker can be granted in Records once you connect it. A kit grants only the ones its job needs, and you can narrow them further on the worker.

List Record Collections

Discover collections in Records, WorkerKit's built-in structured store; no external connection is needed. Use this when the collection slug is unknown. Lists account-shared collections and this worker's private collections, with slug, scope, declared columns and rowCount. Other workers' private collections are excluded. Rows are fetched with tools, not automatically included in context. If the required collection is missing, initialize it only when the workflow calls for that and records_create_collection is granted; otherwise report the missing prerequisite. Do not substitute an unrelated collection.

Create a Record Collection

Initialize a collection in WorkerKit's built-in Records store, or return the existing collection at the same slug and scope. Requires create_collection even when the collection exists; enabling Records alone creates nothing. Set scope explicitly: 'worker' for this worker's private ledger, 'account' (the default) for state shared with other Records-enabled workers under their operation grants. Private is worker isolation; the account owner can manage both scopes. A worker-scope collection is deleted with its worker; state that must outlive the worker (a seen-ledger across reinstalls) is account scope. Use one collection per kind of data, not per run or item (at most 50 per account). Declared columns describe the owner's table view; they do not enforce a row schema. Repeated initialization is idempotent, not an atomic claim on a row or external action.

Query Records

Read rows from a collection, narrowed server-side: `keys` (an exact list of up to 100 keys: the rows that exist come back, so one call checks a whole batch of candidates against a seen-ledger), `keyPrefix` (keys starting with a string), `where` (top-level field equality, e.g. {"status":"new"}), `updatedSince` (ISO 8601), sorted by key or updated_at, paged with take/page (max 200 per page). The response carries totalCount and hasMore: stop paging when hasMore is false. Use keys, keyPrefix or updatedSince to narrow before a `where` on a large collection: the filter scans at most 5,000 rows in range and refuses beyond that rather than answer from a partial scan. Each row carries who wrote it and from which run. For one known key use records_get; for the size alone use records_count.

Get a Record

Read one row by its exact key: the cheapest read when your instruction or an earlier step already gives you the key (a domain, an id). Not found means no row has that key in this collection. To check many candidates against a seen-ledger at once use records_query with `keys`; to browse keys use records_query.

Write Records

Insert or replace up to 100 rows in an existing WorkerKit Records collection by stable key. Include every field that must survive: matching rows are replaced whole. Each data object is at most 4 KB. Ordinary batches may partially succeed: check inserted, updated and rejected[]. To commit a processed page and its checkpoint together, pass ifRowsMatch with the checkpoint key and its version from records_get/query (null if absent), and write that key in the same batch. This requires read and write grants; any conflict or rejected row writes nothing. After RECORD_CONFLICT, re-read and reconcile, including a possibly committed response lost in transit. Conditional state protects progress, not exactly-once external delivery: record completion only after a confirmed action, and reconcile uncertain delivery before retrying. Limits include invalid keys/data, sensitive identifiers, 20,000 rows per collection, account bytes and a worker row budget (normally 5,000). At capacity, update existing keys or follow authorized cleanup.

Delete Records

Delete up to 100 rows by key in one call. Keys that are not present are reported in accessInfo, not errors; the response reports deleted, rowCount and rejected[]. Deleting a row frees its last writer's row budget. Prefer updating a row's status over deleting it when another worker may still be working from it.

Count Records

How many rows a collection holds, from its maintained counter (no scan, no page walk). Use it to size a job before querying, to report progress, or to check headroom against the 20,000-row collection cap. It is not a filter: to count rows matching a condition use records_query with `where` and read totalCount.