Datasets

Tables your agents read, write and act on.

A dataset is a table with columns you define, read and written by your agents and your team, and an agent reads only the rows it needs, never a file that grows without end. In ctxflows, the context layer and the workflows for agent-built software, a dataset can also start a workflow the moment it reaches a condition you set.

Tables with columns you define

Create a dataset when you need one and define its columns, each with a name, a type and a meaning that tells whoever writes what goes in it.

A key groups the rows of each thing you track, a row that breaks a column's rules is refused with every fault named, and columns change with your work without losing their values.

Read and written by agents and people

Your agents add and read rows over the same connection they use for everything else, and your team works in the same table in the web app.

A read takes only the rows it needs, such as one key's or the newest, never a file that grows with every change, and every row records who wrote it, a person or an agent, and from which run.

Start a workflow when a threshold is reached

A dataset can start a workflow the moment its rows reach a condition you set, such as one error's count passing a threshold.

The run starts with the row that reached it, so your agents act the moment the number is there, and nobody has to watch it.

Ledgers and logs

A ledger is a dataset that keeps adding rows, such as every production error seen, each audit's findings or every release.

Lock a ledger against edits or removal, and its history stays as it was written: an agent can set a lock but never clear one.

Shared state between agents

Agents working at the same time share state through a dataset: each reads the rows it needs, writes its own, and holds a row while it works on it.

No agent reads another's conversation, so running several doesn't multiply what each one reads, and when two change the same row at once, neither change is silently lost.

Ready for analytics

Every row is typed, dated and signed with who wrote it and in which run, so a dataset is ready to count, chart and compare as it is.

Read a dataset in Analytics beside what your runs cost, or let a workflow report the trend. Nothing needs cleaning first.

An error ledger

A triage workflow keeps a ledger of your production errors, so the same error never opens two items, and one that keeps coming back raises the alarm by itself.

  1. Define the columns

    One column for each thing worth knowing, with the error's signature as the key.

  2. A new error starts the triage run

    Your error tracker posts the error to your triage workflow's webhook, and the run looks the error up in the ledger.

  3. A new error gets a row and a bug

    An error with no row gets one, and a bug in Reported on your triage board, with the row pointing to the bug.

  4. A known error opens no second item

    The run files nothing new, and adds a row only when the count or the severity moved, so the ledger holds changes, not noise.

  5. A count past your threshold starts a workflow

    When one error's count passes the threshold you set, the ledger starts your escalation workflow on that error, before anyone has to spot the number.

  6. Lock it against removal

    Runs keep adding rows, and none of them can remove the history.

ColumnTypeMeaning
SignatureText, the keyWhat identifies the error, as your error tracker reports it
First seenDateThe day it first appeared
OccurrencesWhole numberHow often it has occurred so far
SeverityText: low, medium or highHow much it hurts the people who meet it
BugReference to a bugThe bug filed for it
FixedYes or noWhether the bug's fix has landed

Every triage run starts from the ledger, not your error tracker's whole history: no error is filed twice, one that returns after its fix shows at once, and one that keeps growing starts its own workflow.

Questions about datasets

Dataset or record: where should my agents keep structured memory?

In a dataset when the same kind of result comes back again and again, one row each time, such as a weekly review. In a record when it's one document that changes over time, such as a plan, whose earlier versions you can read back.

How do my agents write rows?

Over the same MCP connection they use for everything else, from your own session or from a workflow's run. A run nobody watches edits or removes rows only where its workflow allows it.

Can a dataset start a workflow?

Yes. Set a condition on a dataset, such as one error's count passing a threshold, and a workflow starts on the row that reached it.

Can people edit rows too?

Yes. Add and edit rows in the web app, in the same table your agents write to. A lock binds everyone, you and your agents alike.

Can several agents write to one dataset at once?

Yes. Every write is checked against the columns you defined, and when two agents change the same row at once, neither change is silently lost.

Can I export a dataset as CSV?

Yes. Take any dataset out as a CSV file, as you can everything else you keep in ctxflows.

Create the table your work needs

Define its columns once, and your agents and your team keep it current.

Beta accessSee pricing