Agents and tables

An agent is only as useful as what it can do and what it can remember. Here, both come from the platform itself.

The whole platform is the toolbox

An agent node with a scheduled trigger on the left and its tools fanned out on the right: a sub-agent that downloads whitelisted sites, and tools to save and list rows in a table

To give an agent a tool, you draw a line from the agent to any block: a table, a search, a SQL query, a PDF reader, another agent, or a whole other pipeline. Building an agent is the same drag and drop as building a pipeline, and afterwards you can see every tool call it made.

In the screenshot an agent runs every morning, looks up new concerts in Prague and saves them to a table, using a helper agent that is only allowed to visit a few websites.

Somewhere to keep what they learn

Agents get their own tables, real database tables they can define themselves, so what they find is structured and queryable rather than buried in chat logs.

Table editor showing a dynamic table owned by an agent, with typed columns and rows

On top of the tables are views (lists, boards, calendars, dashboards) so people can see and use what the agents produce. I built the table views, and a lighter records store for data whose shape is still changing.

A configured view over an agent's table

Put together, this is a place where agents can actually do ongoing work: they react to new tickets from Jira or Salesforce, keep their findings in tables, and show them to people in views.