an airtable assistant that learns the table before writing

what a bot can do in Airtable

ask the bot to inspect the base schema before interpreting a record. column names can look familiar while meaning something specific to your team. these actions cover finding the base, reading its structure and checking records, with writing kept as a separate choice.

composio, the connection service dusk bot uses for apps, lists 28 Airtable actions (catalog version 20261101_00, read 12 november 2026⁴). dusk bot treats 8 of them as reads, 1 as sends and the other 19 as changes. an action counts as a read only when its name starts with a read word like get, list or search, so a bot you allow only to read can never call the rest. a send is anything that reaches a person outside the app or moves money, like create comment: it waits for your Allow unless you've given that bot a daily amount it may send alone.

connect Airtable

1. open Connected apps in the sidebar.
2. pick Airtable and sign in on Airtable's own page, so your password goes to them and never to a bot.
3. choose which bots may use it, and whether each may only read or may also change things. your bookkeeper doesn't need your Airtable.
4. ask in plain words. reading and drafting happen freely; sending asks you first.

connect airtable in Connected apps and give your records bot read-only access for its first review. name the base and table, then ask it to describe the fields it will use. when you later allow writing, use the exact actions the job needs rather than giving an intake bot access to field or table changes.

routines to copy

these routines use three different tables people often maintain. replace the table references with your own and explain the relevant fields.

every monday at 9, read the airtable content table i specified. check records due this week against our required title, owner and asset fields. list missing values and inspect attachment information where relevant. do not change publishing status or dates.

every thursday at noon, review the airtable event table i named. compare upcoming records with our venue and contact checklist. inspect record comments before flagging a question as unanswered. leave uncertain answers marked as questions and do not edit records.

every weekday at 5, review the intake items i marked approved in this chat. inspect the airtable table schema, check for an existing matching record using the match rule i supplied, and ask me before adding new rows. bring uncertain matches here without overwriting anything.

what it asks you first

the readiness and logistics reviews can stay read only. the intake routine needs record creation, and it explicitly requests your review before adding rows. adding or changing records may not ask first.

keep field creation, table updates and deletion outside the intake bot's allowed actions. if you enable record edits, write "ask me before you change anything" when you want every proposed change reviewed. sends through connected apps ask first by default, with an optional daily allowance, but that setting doesn't cover changes inside a base. one exception: a bot on Full access with no sending rule of its own may send up to 25 a day without asking, so give full-access bots Ask every time under sending.

what it cannot do

• add intake rows, upload attachments or repair records with read-only access. it can prepare the proposed values in your dusk bot chat instead.
• decide what a blank field means without your rule. it might mean not supplied, not needed, or awaiting a decision; tell the routine which cases to flag.
• guarantee that an intake item is new just because its title differs. supply a matching rule and have the bot report ambiguous records rather than overwrite them.
• run an evening intake job on a computer that has gone to sleep. your local routines require an awake computer and running dusk bot; dusk cloud keeps scheduled work available with that computer off.

a schema check is part of the job

have the bot show which fields it will read and which it intends to fill. give required values and a rule for matching existing records. a field that looks like a free-text note may carry a team convention the bot does not know.

if your work is mainly a spreadsheet, compare the google sheets integration. if the source is a workspace page, inspect the separate notion integration before planning a cross-app job.

make intake easy to inspect

keep approved intake items in a small batch and name the target table. ask the bot to return the destination records after creating them, so you can compare the saved values with what you supplied. a file organisation routine can plan where supporting files go.