Fill a table from a connector with a recipe

A recipe moves a connector's results into one of your tables, on Tulina's side. It says which tool to call, which field goes to which column, and which column identifies a row. Your agent writes it once. After that, Tulina runs it as often as you like, and no model reads or retypes the rows.

Who this is for. Anyone whose agent keeps pulling the same kind of list into a table: search results, the people at each company in a table, job offers for a list of domains.

Why use one

• Cheaper. You pay for the connector calls, not for a model reading and copying hundreds of rows into a table.
• Exact. Values land in the table as the connector returned them. Nothing is paraphrased or skipped by mistake.
• Repeatable. The same recipe gives the same result next week. Rows that are already in the table are left untouched, so a re-run never duplicates.
• Bounded. Every recipe has a spending cap. It stops there, never past it.

The four steps

1. Sample. The agent calls the tool once and looks at what comes back: which fields exist and how full they are.
2. Test. The agent tries the recipe on one real page. Nothing is written. It sees how full each column would be.
3. Publish. Tulina runs that test page once more. If it builds at least one row, the recipe goes into service.
4. Run. The recipe writes into your table. You get counts back: rows written, updated, left as they were, filtered out.

A big run goes page by page. If it stops on a limit, it hands back a resume point, and the next run carries on from there without paying for the pages already done.

For each row of a table

A recipe can also go through a table row by row: for each company, find its people; for each domain, find its job offers.

Each row then gets a status in a column you choose:

• done: results were found and written,
• empty: the call worked but found nothing,
• failed: the connector refused this row (for example, an unknown company).

A row whose input is empty (no company name, no domain) is not called, because you would pay for nothing. It stays waiting until you fill it in, and the run tells you how many such rows it skipped.

Rows that already have a status are not called again. To redo a row, clear its status.

The safeguards

• Read-only tools only. A recipe can call a tool that reads (a search, a lookup), never one that sends, posts or changes something. Anything else is refused before a single call.
• A spending cap is required. There is no default: the agent has to set one, in the connector's own units.
• Only a published version writes. A draft can be tested, never run.
• Your rights, nothing more. A recipe writes only into tables you can already write to.
• Watched for changes. If a column that was full at publishing comes back empty on a whole page, the connector's format has probably changed. The run stops and says so, instead of filling your table with blanks.

What it does not do (yet)

• No schedule. A recipe runs when your agent runs it. To run it every morning, put it in a scheduled agent.
• No writing to a CRM or sending. A recipe reads from a connector and writes into a Tulina table, nothing else.
• No reasoning. A recipe copies fields. To judge or qualify rows, use Jev on the table afterwards.

What to ask your agent

"Turn this search into a recipe that writes into my Leads table, keyed on the LinkedIn URL. Test it, show me the fill rate, then publish it."

"For each company in my Accounts table, find its marketing people with a recipe. Status column: people_status. Keep the spending cap low for the first run."

"Run the new-offers recipe again and tell me what it added."