·

Real World Workflow Requirements Lifecycle Management

Walk through a real production workflow that uses Airtable MCP so your AI agent can read and update bases and records end to end.

Everything in this module so far has been per-tool mechanics. This topic assembles those pieces into a single end-to-end workflow: a requirement enters the system as raw, messy text — a Slack thread excerpt, a support ticket, a sales call note — and exits as a delivered feature with a clean audit trail in Airtable. The workflow below is built around Claude Code as the primary driver (for its write discipline) with notes on where you'd swap in another client.

Workflow Overview: From Intake to Delivered Feature in Airtable

The full lifecycle has four stages, each with a distinct Airtable table or view involved:

  1. Intake — unstructured input becomes a normalized Requirements record in a Backlog status, deduplicated against existing records.
  2. Enrichment — an AI pass adds effort estimate, dependency links, and priority, staged for human review rather than auto-approved.
  3. Planning — a human (not the agent) moves approved records into a sprint via the Sprint field, which is intentionally kept out of AI write scope.
  4. Delivery sync — code and issue-tracker events (PR merged, CI passed, deploy completed) flip Status forward automatically, closing the loop without manual tracker updates.

The base schema underpinning this, if you're setting it up fresh:

Requirements table fields:
- Title (single line text)
- Description (long text)
- Source (single select: Slack, Support Ticket, Sales Call, Internal)
- Status (single select: Backlog, Approved, In Progress, In Review, Shipped, Blocked)
- Priority (single select: P0, P1, P2, P3)
- Effort Estimate (single select: XS, S, M, L, XL)
- Dependencies (link to Requirements — self-referencing)
- Epic (link to Epics table)
- Sprint (single select, human-only field)
- Requirement ID (formula: "REQ-" & RECORD_ID(), or an autonumber field)
- AI Notes (long text — audit trail of what the agent did and why)
- AI Confidence (single select: High, Medium, Low)
- Last AI Action (date, with time)

The AI Notes and Last AI Action fields aren't decorative — they're the difference between "the agent did something to this record at some point" and an actual audit trail you can review during a retro or debug when a status looks wrong.

Tips
- Keep at least one field (Sprint, in this schema) explicitly out of AI write scope by convention and by prompt discipline — not every field needs to be automatable just because it can be.
- Build the AI Notes / AI Confidence / Last AI Action triad into any table an agent regularly writes to, regardless of which specific workflow you run — it pays for itself the first time you need to explain an unexpected status change.
- Treat this four-stage split as a template, not a mandate — the actual value is separating "AI can do this safely" from "a human decides this" at the field level, not the specific field names chosen here.

Step 1: Capturing and Normalizing Incoming Requirements as Records

Raw input rarely arrives as a clean requirement. A support ticket excerpt looks like this:

Subject: Re: Export request
Body: Hey, we've had 3 customers this month ask if they can export the whole
feature comparison table as a CSV instead of screenshotting it for their
procurement team. Seems like a quick win? - Jamie, CS

The intake prompt turns this into a structured record, with an explicit dedup check first:

Here's a support ticket excerpt: [paste text above]

1. Search existing Requirements for anything similar (search Title and
   Description for "export" and "CSV" and "feature comparison").
2. If nothing matches, create a new record:
   - Title: a concise, action-oriented title (not a copy of the raw text)
   - Description: cleaned-up summary preserving the "why" (3 customers asked, procurement use case)
   - Source: "Support Ticket"
   - Status: "Backlog"
   - Priority: leave blank, do not guess — that's a human decision at intake
   - AI Notes: "Created from support ticket excerpt, 2026-08-21. Original requester: Jamie (CS)."
3. If something matches, don't create a duplicate — instead add a note to
   the existing record's AI Notes: "Additional request received 2026-08-21,
   same theme as existing record."

Note the explicit "do not guess" on Priority — this is a deliberate scope limit. Priority is a business decision informed by context the agent doesn't reliably have (roadmap commitments, deal dependencies), and letting it default to a guess here is exactly the kind of automation that erodes trust in the system once someone notices three low-effort requests got auto-tagged P1 while a genuinely urgent one sat at P3.

Resulting create payload if no duplicate is found:

{
  "fields": {
    "Title": "Add CSV export for feature comparison table",
    "Description": "Multiple customers (3 this month via CS) need to export the feature/plan comparison as CSV for internal procurement review, rather than relying on screenshots.",
    "Source": "Support Ticket",
    "Status": "Backlog",
    "AI Notes": "Created from support ticket excerpt, 2026-08-21. Original requester: Jamie (CS)."
  }
}

For higher-volume intake (say, a weekly batch of 15-20 raw items pasted from a shared doc), run the dedup-then-create loop per item rather than batching the creates blindly — the dedup check is what prevents the backlog from filling with near-duplicate records that differ only in phrasing, which is a real and common failure mode when intake volume goes up.

Tips
- Always dedup-check before creating, even when it feels like obvious overhead for a single new request — backlog duplication compounds silently and is expensive to clean up later.
- Explicitly exclude business-judgment fields (Priority, in this example) from AI auto-fill at intake — let the agent normalize and structure, not prioritize, unless you've deliberately decided otherwise.
- Preserve the "why" in the Description, not just the "what" — a title like "Add CSV export" without the procurement-use-case context loses the information a future prioritization conversation actually needs.

Step 2: Enriching Records with Effort, Dependencies, and Priority via AI

Once a batch of records sits in Backlog with clean titles and descriptions, an enrichment pass adds the fields that inform planning — but every enrichment write here should be a proposal first, not a committed value, because these are exactly the fields humans will disagree with the agent about most often.

For all Requirements records in Status = "Backlog" with no Effort Estimate set:

1. Read the Description and compare against similar past requirements
   (search for records with overlapping keywords in Title/Description that
   already have an Effort Estimate and are Shipped).
2. Propose an Effort Estimate (XS/S/M/L/XL) based on that comparison.
3. Check the Description for mentions of other features, systems, or
   third-party integrations that suggest a Dependencies link — search
   Requirements for matching titles.
4. Write your proposals to AI Notes as a suggestion, e.g.
   "AI suggests: Effort = M (similar to REQ-410, comparable scope), possible
   dependency on REQ-455 (billing API) — please confirm."
5. Do NOT write directly to Effort Estimate, Dependencies, or Priority fields.
   Set AI Confidence to Medium or Low depending on how close the comparable
   match was.

This produces a write like:

{
  "fields": {
    "AI Notes": "AI suggests: Effort = M (similar scope to REQ-410 — same export/rendering pattern, shipped in 2 weeks), possible dependency on REQ-455 (billing API export permissions) — please confirm before setting.",
    "AI Confidence": "Medium"
  }
}

A human then reviews the AI Notes column (a filtered view: Status = "Backlog" AND {AI Notes} != "" AND {Effort Estimate} = "" surfaces exactly the records awaiting review) and either accepts the suggestion by setting the real field, or overrides it. Only after a track record of the AI's estimates holding up over several sprints would a team reasonably consider promoting this to direct-write — and even then, keeping the human-confirm step for Dependencies specifically is worth keeping permanently, because a wrong dependency link can quietly block an unrelated requirement's planning.

For records where the agent found a strong comparable (AI Confidence = High) across many sprints running, some teams do eventually loosen this to direct-write for Effort Estimate only, while keeping Priority and Dependencies human-gated indefinitely. That's a reasonable maturity curve — start fully staged, loosen selectively once you have evidence the specific field's suggestions are reliable.

Tips
- Stage every enrichment suggestion in a review field first; don't wire an agent to write directly into planning-critical fields (Effort, Priority, Dependencies) until you have sprints of evidence its suggestions are consistently good.
- Build a saved Airtable view filtering exactly "has an AI suggestion, not yet confirmed" — it turns review from a manual scan into a five-minute daily habit.
- If you do eventually promote a field to direct AI write, do it one field at a time based on actual track record, not all at once — Effort Estimate accuracy and Dependency accuracy are genuinely different problems with different failure costs.

Step 3: Syncing Delivery Status Back from Code and Issue Trackers

This is the payoff stage — the part of the lifecycle that used to depend on someone remembering to update Airtable, now driven by actual signals from GitHub/GitLab and CI.

On PR open, tag the requirement as in progress:

A new PR was opened: "REQ-482: Add CSV export for feature comparison table".
Find the matching Requirements record (match Requirement ID in the PR title
against the Requirement ID field), set Status to "In Progress" if it's
currently "Approved" or "Backlog", and add to AI Notes: "PR #221 opened,
2026-08-21."

On PR merged, advance to review or shipped depending on your deploy model:

PR #221 (REQ-482) just merged to main. If this repo auto-deploys on merge,
set Status to "Shipped" and Shipped Date to today. If it requires a manual
release step, set Status to "In Review" instead and note "Merged, pending
release" in AI Notes.

The conditional here matters — teams with continuous deployment and teams with a manual release train need different terminal states, and hardcoding "merge = shipped" is wrong for the latter group. Tell the agent which model your repo follows rather than letting it assume.

On deploy completion (for the manual-release case), a follow-up:

Release v2.14.0 just deployed to production, including PRs #221, #224, #229.
For each, find the matching Requirements record by Requirement ID referenced
in the PR title, set Status to "Shipped", Shipped Date to 2026-08-21, and
append to AI Notes: "Shipped in release v2.14.0."

Batched write for the three matched records:

{
  "records": [
    { "id": "recAAA111", "fields": { "Status": "Shipped", "Shipped Date": "2026-08-21", "AI Notes": "Shipped in release v2.14.0." } },
    { "id": "recBBB222", "fields": { "Status": "Shipped", "Shipped Date": "2026-08-21", "AI Notes": "Shipped in release v2.14.0." } },
    { "id": "recCCC333", "fields": { "Status": "Shipped", "Shipped Date": "2026-08-21", "AI Notes": "Shipped in release v2.14.0." } }
  ]
}

Wiring this into your actual pipeline rather than typing it manually is the last piece — a GitHub Action or CI post-deploy step that shells out to invoke Claude Code non-interactively (claude -p "..." with the deploy manifest) turns this from "a nice pattern I do sometimes" into "the status field is always accurate." Worth flagging honestly: this only works as well as your PR-title-to-Requirement-ID convention is followed. If developers merge PRs without the REQ-nnn reference, the sync has nothing to match against, and no amount of agent sophistication fixes an inconsistent human convention upstream of it.

Tips
- Make the Requirement-ID-in-PR-title convention a PR template default or a CI lint check, not just a wiki page nobody reads — the entire delivery-sync stage depends on that string being present and correctly formatted.
- Branch the merge-to-status logic on your actual deploy model (continuous vs. manual release) explicitly in the prompt or automation script — don't let "merged" and "shipped" get conflated for teams with a release gate.
- Run the delivery-sync step from CI/CD non-interactively rather than manually, once you trust the pattern — this is the one place in the whole lifecycle where full automation without a review gate is appropriate, because the source of truth (merge event, deploy event) is an unambiguous fact, not a judgment call.

Tips

Tips
- Treat this four-stage lifecycle as a spectrum of trust, not a uniform automation policy — intake normalization and delivery-status sync are safe to fully automate because they're mechanical; enrichment and prioritization stay human-reviewed because they're judgment calls.
- Instrument every stage with an audit trail (AI Notes, Last AI Action) from day one — retrofitting an audit trail after the first "why does this record say Shipped" question is much more painful than building it in up front.
- Revisit which fields are AI-direct-write versus human-gated every quarter as you accumulate a track record — the right automation boundary for a new workflow is not the right boundary six months in, in either direction.