Building an Asynchronous Event-Driven Agentic Framework for AI-Powered App Building

airtable · Tech · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Agentic app-building platform

Airtable needed a production agent framework that could power Omni and Field Agents by handling multi-step reasoning, dynamic decisions, tool calls, large context, and self-correction across app-building workflows.

Constraints:

Earlier AI features could not handle dynamic decision-making or additional data retrieval.
Agents needed to maintain session, guideline, event, and tool-output context.
Tool outputs and long conversations can exceed provider context windows.
Airtable wanted control over prompts, abstractions, and observability.

Architecture

Airtable built an asynchronous event-driven state machine with three main components: a context manager, tool dispatcher, and decision engine. Events such as user messages, tool calls, tool outputs, and LLM messages drive the loop. The decision engine uses an LLM to choose the next step, the tool dispatcher runs predefined tools, and the context manager records guidelines, session, and event history. Context truncation, message removal, and summary-of-summaries patterns manage long contexts.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user[User] --> agent-state-machine[Agent State Machine]
  agent-state-machine --> context-manager[Context Manager]
  context-manager --> decision-engine[Decision Engine]
  decision-engine --> tool-dispatcher[Tool Dispatcher]
  tool-dispatcher --> airtable-tools[Airtable Tools]
  tool-dispatcher --> agent-state-machine[Agent State Machine]
  context-compression[Context Compression] --> context-manager[Context Manager]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`User`	Airtable user requesting app-building or field-agent work.	`Agent State Machine`
`Agent State Machine`	Event loop that consumes events and keeps the agent moving.	`Context Manager`, `Decision Engine`, `Tool Dispatcher`
`Context Manager`	Maintains guideline, session, and event context.	`Agent State Machine`, `Decision Engine`
`Decision Engine`	LLM-backed brain that chooses tools, fixed workflows, human-in-loop, or final responses.	`Context Manager`, `Tool Dispatcher`
`Tool Dispatcher`	Runs predefined tools and emits tool-output events.	`Decision Engine`, `Airtable Tools`
`Airtable Tools`	Actions for data retrieval, base analysis, interface building, internet search, or content generation.	`Tool Dispatcher`
`Context Compression`	Truncates tool outputs, removes older messages, or summarizes large workloads.	`Context Manager`

Data flow

A user message produces an event. The context manager records it, the decision engine serializes context for the provider and decides whether to call a tool or respond, tool calls are dispatched, tool outputs become new events, and the loop continues until an LLM message event ends the interaction.

“We built our agent as an asynchronous event-driven state machine. The agent would consume and process events; for each event type, a specific component would handle that event. To this end, we created three main components:”article, stated

“2. A tool call event is produced by the decision engine when the backing LLM decides to run a tool to accomplish the user’s request. This triggers the tool dispatcher.”article, stated

Why this architecture

Airtable built its own framework because custom state-machine events, prompt serialization, context controls, and observability mattered more than adopting an off-the-shelf framework. The event-driven design also makes tool failures retriable by feeding error messages back into the LLM.

“However, building our own agent allowed us to avoid over-abstracting components, gave us finer control over prompts, and gave us greater control over observability of the system.”article, stated

“In most cases, with a descriptive error message, the LLM can self-correct and re-run the tool with different arguments, or provide the user with a reason as to why their request failed.”article, stated

Models used: LLM-backed decision engine

Scale

The framework powers Omni and Field Agents.
“Airtable, we’ve built an agentic framework that powers all of our AI features, including Omni, our conversational app builder, and Field Agents, which are AI-powered fields that can autonomously”article, stated
Airtable describes agents that can automate thousands of hours of work in seconds.
“Most recently, we relaunched Airtable as an AI-native app platform, introducing AI agents that can automate thousands of hours of work in seconds.”article, stated
The agent framework handles multiple event types: user messages, tool calls, tool outputs, and LLM messages.
“There are a few main events that the agent consumes and passes to the appropriate components: 1. A user message event is produced by the user sending a message into the interaction. This triggers the decision engine to call the backing LLM to decide what step to take next.”article, stated
Large-base analysis can split records across many LLM calls and aggregate summaries.
“Instead, we divide the records amongst many different LLM calls, have each LLM call perform the request on its set of data, and aggregate the results using another LLM with a summarization prompt, producing what is effectively a ‘summary of summaries.’”article, stated

Alternatives considered (roads not taken)

Use existing agentic frameworks.

Rejected because: Airtable wanted finer prompt, abstraction, and observability control.

“While we could have used an existing agentic framework, we were surprised to find that it wasn’t difficult to build one ourselves. Using agentic frameworks can be useful for quickly building a new system, since they define simple abstractions like tools, chaining, prompt serialization, and”article, stated

Simple upfront-context AI fields.

Rejected because: They could not retrieve additional data or reason through dynamic tasks.

“While the original AI capabilities above were great for a variety of simple use cases, they were incapable of reasoning through problems that required dynamic decision making or retrieving additional data beyond what had been provided upfront.”article, stated

Pull all large-base records into one LLM context.

Rejected because: Large bases exceed practical context windows.

“for large bases, asking a question such as, “Analyze the sentiment across all the feedback” would require us to pull in content from all records into the LLM. Instead, we divide the records amongst many different LLM calls, have each LLM call perform the request on its set of data, and aggregate”article, stated

Patterns

`tool-use-orchestration` (agent-framework)

The decision engine emits tool-call events and the dispatcher runs predefined tools.

“The tool dispatcher exposes tools (predefined actions) to the agent and runs tools when requested.”article, stated

`context-compaction` (context-engineering)

Airtable truncates tool outputs, removes older messages, and summarizes large work across many calls.

“we’ll start removing messages from earlier in the thread”article, stated

`fallback-degradation` (error-handling)

Retriable tool errors are passed back to the LLM so it can self-correct or explain failure.

“Tool call output events trigger the decision engine, and the tool call failure information is passed back to the LLM.”article, stated

Tradeoffs

Framework ownership

Chose Build a custom event-driven framework over Adopt an existing agentic framework.

Rationale: Custom framework reduced over-abstraction and improved prompt and observability control.

“gave us greater control over observability of the system.”article, stated

Large-base analysis

Chose Many LLM calls plus summarization aggregation over One huge context call.

Rationale: This avoids pulling all records into one context window.

“aggregate the results using another LLM with a summarization prompt”article, stated

Gotchas (what bit them)

Context windows force selection even in agent frameworks.

Root cause: Guidelines, session state, event history, and tool outputs can exceed finite limits.

Resolution: Truncate older tool outputs first, then remove older messages if needed.

“context windows have finite limits and as a result, we must sometimes select the most relevant context”article, stated

Tool errors must be designed for LLM recovery.

Root cause: Opaque failures leave the decision engine without actionable next steps.

Resolution: Return errors with a helpful retriable message for the LLM.

“A helpful message to expose to the decision engine (LLM) if the error is retriable”article, stated

Evaluation

The article emphasizes operational correctness through event handling, retriable tool errors, context-window heuristics, and iteration speed rather than a named benchmark.

Metrics: Tool-call success · Self-correction after retriable errors · Context fit · Iteration speed · Agent capability coverage

“our ability to quickly iterate on the agent was significantly improved.”article, stated

Outcomes

Airtable's custom framework powers Omni and Field Agents.
Agents can reason, plan, orchestrate actions, and self-correct on tool errors.
The framework supports context engineering for large bases and long interactions.

The source describes all Airtable AI features, thousands of hours automated in seconds, multiple event types, large-base fanout across many LLM calls, and ongoing context-engineering work.

“capable of reasoning, planning, and orchestrating actions to accomplish complex tasks with minimal input.”article, stated