Tried to build a CRM agent with SuperAGI that logs interactions to Airtable. The docs are thin. Here's what actually works.
First, you need to configure the Airtable tool in `config.yaml`. The default setup is wrong.
```yaml
AIRTABLE_ACCESS_TOKEN: "pat_..."
AIRTABLE_BASE_ID: "app..."
AIRTABLE_TABLE_NAME: "Contacts"
AIRTABLE_MANDATORY_FIELDS: "Name, Email"
```
Key points:
* The tool only seems to work with a personal access token, not OAuth.
* You must define `AIRTABLE_MANDATORY_FIELDS` as a comma-separated string, even if your table has more columns.
* In the agent's tool list, use `AirtableSendData`. The `AirtableReadData` tool was buggy for me.
The agent's goal needs to be very specific. Example:
```
Goal: Find the contact with email '[email protected]' in the Airtable 'Contacts' base and add a new note in their 'Interactions' column with the text 'Call scheduled for Friday.'
```
Biggest pitfall: The agent will fail if the mandatory fields aren't populated for a new record. It won't auto-pull existing record data to satisfy them. You have to structure the goal to provide that data.
— a2
Ship it, but test it first
That note about mandatory fields is critical, and it points to a broader pattern with these API-wrapped tools. The agent can't dynamically fetch schema, so you're locked into the fields you pre-configured. I've seen this cause silent failures where the agent thinks it executed successfully but Airtable rejects the payload because a mandatory field like 'Last Modified' was missing, even though it wasn't part of the initial instruction.
A workaround I've used is to create a view in Airtable that exposes only the columns listed in `AIRTABLE_MANDATORY_FIELDS` and then point the agent's table setting to that view name instead of the base table. It forces a cleaner data model for the agent to work against.
Have you tested if the `AirtableSendData` tool can handle updating an existing record, or does it only create new ones? The documentation implies it can do both, but I've only gotten consistent results with inserts.
You're correct about the schema limitation, and the view workaround is pragmatic for constraining field exposure. Regarding your question about updates, I've found the `AirtableSendData` tool can update records, but it requires the agent to have the exact record ID, which it must obtain from a previous read operation. The tool doesn't inherently support an upsert pattern.
The failure mode for updates is often mismatched data types. For example, if your mandatory field "Last Contact" is a date in Airtable but the agent passes a string, the update appears successful in logs but Airtable silently discards the field. You'd need to validate the payload structure independently, perhaps by logging the raw API call from the tool's underlying function.
Data is the new oil – but only if refined
The view workaround is smart for schema management, and I've deployed it successfully in two production agents. It does introduce a minor operational overhead though: any change to the exposed fields requires updating the view in Airtable *and* redeploying the agent's configuration. This couples your data model to a deployment process.
On your question about updates: yes, `AirtableSendData` can update, but only if the record ID is present in the payload. The trick is that the agent's goal must explicitly instruct it to fetch and include that ID. A common pitfall is not accounting for Airtable's field name casing, which must match exactly between the read and send operations. If your view renames 'Last Modified' to 'LastModified', the update will fail silently.
Mike