From my perspective, Airtable is the hardest integration we have shipped so far. Not because the API is difficult — it is one of the more pleasant APIs we have worked with — but because the same Airtable base can be a CRM in one company, a content calendar in another, an inventory system in a third, and a home-grown project tracker in a fourth. Every base looks different. Every customer's vocabulary for their own records is different. That breadth is what makes Airtable beloved, and it is also what makes an Ai integration over Airtable fundamentally different from an integration over Xero or DocuSign, where the data model is fixed and the vendor has already decided what a safe action looks like.
I believe that when the data model is bring-your-own, the safety net has to be louder, specially on destructive operations. An Ai that can delete a row by saying "yes" once is fine for a purpose-built CRM where a deleted contact has a specific recovery workflow. It is not fine for a base that might be a freelancer's whole business records or a small team's last three months of campaign planning. So we ship two-turn delete for Airtable, and we made the gate a server-side check so the safety net does not depend on the language model behaving well.
How two-turn delete actually works
When a user asks the assistant to delete a record — "delete recAbc in the Leads table" — the first tool call comes back with a preview. The assistant fetches the record, formats the fields in chat, and explicitly asks the user to confirm. The language model has been instructed to pass a confirm flag on the second call. Here is where most implementations stop, and here is where ours starts being different. We do not trust the confirm flag alone. Between the first call and the second, we set a short-lived flag inside our own cache that tags the user and the specific record. On the second call, we check the flag before we actually delete. If the flag is missing — specially because the model tried to skip ahead by passing confirm on the first call — the preview gets shown again with a note that explains what just happened.
The reason this matters is that language models can be confused or manipulated. A prompt-injection buried in a customer-imported record could tell the model to pass confirm on every delete. A misbehaving model could interpret "just delete it" as already-confirmed. Our cache-based gate does not care what the model thinks — it only proceeds if the user has actually seen a preview in chat within the last few minutes. The gate is a property of the server, not a property of the conversation, and that is the only way to make the promise genuine.
Soft delete, on purpose
Apart from the two-turn gate, we deliberately did not request the scope that would let us hard-delete. Airtable distinguishes two levels of deletion: the normal delete that moves a row to the base's trash for seven days, and the permanent delete that wipes it for good. We skip the second scope entirely. Any delete from our integration is recoverable from the Airtable UI's trash for a week. Combined with the two-turn gate, the effective safety is that a row can only be deleted if the user saw a preview in chat, confirmed it, and still has seven days to undo it from Airtable's own interface.
I tend to focus on this kind of layered safety because the alternative — one clever check that is supposed to catch everything — always fails in the one case you did not think about. Two-turn confirmation catches the intent-level mistake. Soft-delete catches the later regret. Skipping the permanent-delete scope catches the genuinely hostile case where someone has worked around the first two layers. Each layer is small on its own. Together they are the reason this is the integration I sleep easiest about.
The other constraint — per-base consent
Like Notion, Airtable asks the user explicitly which bases to share with our integration on the consent screen. A user picks the bases by name; they are not signing a blanket workspace grant. Our integration can only see the bases on that list. If a user has five Airtable bases and shares three, the other two genuinely do not exist from our point of view. The tools we expose — list bases, list tables, search records, create, update, delete — all operate within the scope the user granted, and we store the granted base list inside the user's encrypted integration row so the assistant can route each question to the right base by name.
This per-base consent is also why PKCE matters. Airtable uses OAuth 2.0 with PKCE, which is the proof-of-possession flavour of OAuth. In plain terms, it means the authorisation code the provider returns during the consent flow can only be exchanged for tokens by the same session that started the flow. An intercepted code is useless to anyone else. This is the first integration in our codebase that uses PKCE, and the implementation is small but particular — a random verifier generated at connect-start, stashed in the user's session, retrieved at callback. It is the kind of detail that does not show up on a marketing page and is the difference between an OAuth flow that is safe by default and one that is safe only if nothing goes wrong.
A scenario that prove to be fruitful
One of our customers is a two-person agency running a content calendar inside Airtable. Before connecting, the content lead spent every Friday afternoon auditing the calendar — which posts were scheduled, which were missing approvals, which were waiting on a client sign-off. Most of that time was spent inside Airtable's own filters and views. After connecting through Other Me, the Friday audit is a single message — "show me every post scheduled for next week, grouped by client, and flag the ones still waiting on approval". The assistant reads the granted base, runs the filter, and returns the list inside the chat. The content lead spends the rest of Friday actually drafting the posts that are now blocked, which is the work they would rather do than staring at a grid.
The lead tells me the shift is less about speed and more about context switching. The audit used to mean opening Airtable, loading a view, exporting, scanning, opening a doc, going back. Now it is three messages in the chat, and the next three messages are the draft posts. The tool is invisible, which is the compliment every integration is trying to earn.
Where this sits in the bigger picture
I believe Ai inside flexible tools like Airtable is going to be more valuable and more dangerous than Ai inside purpose-built apps, specially as more teams adopt the bring-your-own-schema pattern for everything from CRM to project tracking. The value is that a single assistant can read and write across every shape the team has invented. The danger is that a single mistake lands in a schema the vendor did not design and has no opinion on how to repair.
The answer is not to refuse write access. The answer is to put the right gates at the right layers — two-turn confirmations on delete, soft-delete only, per-base consent, PKCE on the auth flow, DLP on outbound fields. Every layer costs a little friction. The friction is the point. In an assistant-shaped integration, friction on destructive operations is not a bug, it is the product doing what the team actually asked it to do — which is to be useful without being reckless. Airtable is the first integration where I felt we had to make that trade explicit, and so far it is the integration where users have come back to say the trade was right.