Four Kitchens × AI: where one person does more.

What this is, and how it was built.

This report is Newfangled's outside-in read of Four Kitchens' engineering ecosystem in May 2026 — what we can see in your public repositories, your team page, your conference talks, and the work you've made open-source. It is a recommendation, not an audit: every observation below is grounded in something we read, but everything we couldn't verify is flagged in the open-questions section near the end.

The spine is opportunity, not threat. AI in 2026 is no longer a productivity tool layered on top of existing work — for a Drupal shop with deep multisite expertise, it changes which person does which piece of work. The body of the report identifies eighteen of those role-compression moments, grouped by who's empowered.

• Research-grounded

  Every claim about Four Kitchens cites a public source — repo, commit, talk, team page. We don't speculate about what you do internally.

• Opportunity-framed

  Each opportunity is framed as "this AI capability lets one person do work that used to require more" — not as "adopt X tool."

• Honest about gaps

  A dedicated section lists what we couldn't determine from outside. Many recommendations soften or sharpen depending on what's true internally.

drupal-ai-standards is already the seed of your AI strategy.

In late April 2026 — barely a month before this report — the initial commit of drupal-ai-standards landed on GitHub: a Composer plugin from day one, with a project-level AGENTS.md scaffold, a three-layer ownership model (shared / project / personal), six initial skills for Drupal-specific tasks, a SECURITY.md with non-negotiables, and an always-on instruction file that codifies WCAG 2.2 AA across 49 specific anti-patterns. We can't see your internal usage. But the architecture decisions in that repo — made very deliberately, very recently — tell us most of what we need to know about how Four Kitchens is now thinking about AI in development work.

What we don't yet see in public: the operational depth around the seed. There is no AGENTS.md scaffold from this plugin checked into any client repository we can read. No FIRE command for invoking the standards from inside CI. No documented adoption metric or before/after measure of AI-assisted output quality. Those are not concerns — they are the work that converts an excellent foundation into a daily-use system, and they shape much of what follows in this report.

The Drupal AI landscape, mid-2026.

The decisions in drupal-ai-standards weren't made in a vacuum. The Drupal AI ecosystem has visibly matured over the past year — through community projects like the AI Module, the AI Agents framework, MCP server integrations, and the broader Drupal CMS 2.0 release. 2026 is the first year in which "Drupal + AI" is no longer a future bet but a working set of patterns several agencies are quietly building on. Three currents matter.

One sentence.

If there is one frame that holds the rest of this report together, it is this.

A lot of the work can be partially or fully automated — freeing the team to think about the harder, bigger problems.

The eighteen builds that follow are specific places where that automation can land — each grouped by the area of work where the savings happen, each named as a concrete thing Four Kitchens could ship.

Savings in engineering practice.

Where senior-engineer hours currently go: reviewing routine PRs, triaging dependency updates, repeating Drupal patterns across client projects, holding institutional context for repos no one else has touched. Four concrete builds reclaim that time.

Savings in project bootstrap.

Every new client engagement carries a setup tax: the first developer figures out the conventions, the AI tools each person uses, the project's particular Drupal model. That tax compounds across the firm. Three builds remove most of it.

Savings in sprint operations.

A meaningful slice of work that currently requires pulling a developer in — story decomposition, content modeling, migration analysis, status reporting, bug triage — can be partially or fully automated, with a project manager at the wheel rather than a developer. This is the largest opportunity in the report, both in hours saved and in scope to make uncomfortable changes. Five builds anchor it.

Savings in editorial workflow.

Editorial workflow is where Four Kitchens already has the most external-facing AI exposure — AskYale, the higher-ed training engagements, the multisite accessibility work. The opportunity is to convert what FK currently delivers as bespoke service hours into continuous in-product capabilities. Three builds.

Savings in delivery and maintenance.

Three builds at the firm level. Each reshapes a unit of work — what discovery is, what a deliverable is, what Continuous Care includes — rather than just compressing inputs.

A twelve-month rollout, in four phases.

The eighteen opportunities don't have to ship at once. They sequence naturally: foundation work that grounds the rest, the developer loop that proves the model internally, PM enablement that extends it past engineering, and finally the editorial and firm-level work that converts capability into deliverable. The dates below are illustrative — adjust to the cadence that fits your delivery commitments.

The rollout assumes Four Kitchens chooses to own this work — but every phase has a "buy the integration, build the standards" variant that trades development cost for time-to-value. We'd recommend discussing those branch points after Phase 1 is locked.

Open questions that would sharpen this report.

Every recommendation in this report is grounded in something we read in public — your repos, your team page, your conference talks. But there are seven questions we couldn't answer from outside, and the answers would meaningfully sharpen — or in some cases reshape — the recommendations.

1. Internal adoption of drupal-ai-standards.

   We can see the repo, but not how many developers actively use it, on which projects, with which IDEs. The "fill in AGENTS.md per client" recommendation softens or intensifies depending on whether you're at 10% or 90% adoption today.

2. Operational state of AskYale today.

   We can see the architecture — LLMs, RAG, Azure OpenAI — but not its current uptime, content volume, query rate, or whether other clients have followed. The "productize AskYale" opportunity depends on whether the original is still the right reference architecture.

3. Existence and shape of an internal AI usage policy.

   You published a responsible-AI-use page externally. Inside the firm, what guides individual developers' choices about which AI tools to use on client work, with what data?

4. The current Continuous Care service shape.

   The "Continuous Care + AI" recommendation assumes a baseline of what's in scope today. If the service has already evolved past where we can see it externally, the recommendation may already be partially shipped.

5. Bundle-classes adoption across client projects.

   drupal-ai-standards includes a bundle-classes skill, but we can't tell how many client projects actually use bundle-classes as the default pattern vs. as an optional. The "AI-safe Drupal development" recommendation is one- or two-sided depending on the answer.

6. POTS vs. newer security tooling — current strategy.

   POTS' AutoSec module still references gpt-3.5-turbo as its model, and that line has not been updated in years. Either POTS is being maintained at minimal cost while another tool takes over, or this is an out-of-date dependency in active use. Different recommendations follow.

7. FIRE command surface — actual usage.

   FIRE is your standardized command set. The "FIRE ai:* commands" opportunity assumes the existing surface is well-used internally. We can see the repo; we can't see the usage.

What we read to write this.

Every observation in this report is grounded in a public source. Where the source is a Four Kitchens repository, the link goes to the relevant tree on GitHub. Where it is a third-party article or post, the link goes to the original. We did not fabricate, paraphrase, or extrapolate beyond what these sources explicitly state.

• drupal-ai-standards
• FIRE
• POTS
• Sous
• sous-recipe
• acquia-cloud-hooks
• Emulsify
• Four Kitchens team page
• Responsible AI Use Policy
• Drupal AI Module
• AI Agents framework
• Drupal CMS

For each opportunity in this report, our internal planning notes carry the specific paragraph or commit that grounds it. If a recommendation surprises — or doesn't match your read of the work — that's where we'd start the conversation.