How we build: the Automaton stack (and why it's different from an "AI agent stack")

If you search "AI agency tech stack" right now, every result answers a different question: what tools do I use to build an AI agent? Reddit threads, LangChain tutorials, vector-database reviews. Useful if you're building agents. Useless if you're running an agency and want to know what your team should actually be running on in 2026.

This post is the other answer. It's the stack we use at Automaton Agency to ship client websites, revenue systems, and internal tools. It's opinionated — every choice is a trade-off we've made consciously and can defend. And because the stack question is inseparable from the philosophy question, we'll start with the philosophy.

The AI agent stack vs. the AI agency stack

There are two different questions hiding behind the phrase "AI agency tech stack":

• The AI agent stack is a toolkit for building autonomous agents — LangGraph, LangChain, vector databases, orchestration frameworks, observability tools. This is a builder's stack.
• The AI agency stack is the set of tools a business called "an AI agency" uses to actually deliver client work — CMS, deployment platform, CRM, automation tools, AI assistants woven into daily operations. This is a practitioner's stack.

Both are valid. They're not the same. Most of the content ranking for this query in 2026 conflates the two — which is convenient for us, because the practitioner question is the one more people actually have and the one nobody is answering directly.

Some context on how large that audience actually is. As of 2026, 91% of marketing agencies now use AI technology in some form, according to Amra & Elma's 2026 adoption report. 87% of marketers use generative AI in at least one workflow — up from 51% in 2024 per Digital Applied. But adoption is not reimagining. McKinsey's 2026 state-of-AI survey found that only 34% of organizations are truly reimagining their businesses through AI. The other two-thirds are bolting it onto existing processes. What stack you pick decides which group you end up in.

Mapping the stack to the five-layer framework

We organize every client build — and our own business — around what we call the five-layer framework for business systems: Data, Systems, Automation, AI, Human strategy. The stack maps cleanly to those layers, and that's not a coincidence. If your tools don't map to a clear architectural frame, you'll stitch them together in ways that make your agency slower, not faster.

Here's the quick index before we go layer by layer:

• Layer 1 — Data: Supabase (Postgres + pgvector + Row Level Security)
• Layer 2 — Systems: Next.js on Vercel, static builds, Supabase Edge Functions, MCP as integration fabric
• Layer 3 — Automation: Zapier for cross-app workflows, HubSpot workflows for CRM logic, Supabase Edge Functions for anything custom (and increasingly for what used to live in Zapier)
• Layer 4 — AI: Anthropic Claude (Sonnet 4.6, Opus 4.6, Haiku 4.5) as the default LLM, Anthropic Agent SDK, Claude Managed Agents for client-facing deployments, MCP servers as the integration fabric, Gemini for image generation
• Layer 5 — Human strategy: A creative technologist sitting above all four layers, deciding where judgment goes and where automation goes

Layer 1: Data — Supabase, Postgres, and why we don't use Firebase

Everything at Automaton runs on Supabase. Not as a "backend-as-a-service" — as the single source of truth. Client websites, our own site, CRM augmentation, AI memory, embeddings for semantic search, scheduled jobs, even the content management for this blog — all Postgres tables behind a Supabase API.

The 2026 numbers make the choice less controversial than it used to be. Supabase passed 1.2 million active developer users in Q1 2026 — a 300% increase from 2025 — and hit a $5B valuation. 99.2K GitHub stars, enterprise-ready security certifications, and customers including Mozilla, Zapier, and Vercel. A year ago you had to justify choosing Supabase over Firebase. Now you have to justify choosing Firebase over Supabase.

The reason we picked it over Firebase isn't just market share. Three concrete things:

1. pgvector is in the box. For the most common 2026 AI workload — semantic search and retrieval-augmented generation — Supabase stores embeddings in the same database as the rest of your data. Firebase uses Vertex AI, which means a second system, a second bill, and a second security model.
2. Predictable pricing. Supabase's tier-based model is 3-5x cheaper at scale than Firebase's pay-per-read, per independent 2026 comparisons. For an agency billing fixed-price projects, predictability matters more than the headline price.
3. Edge function cold starts: 42ms. That's roughly 10x faster than the equivalent Firebase Cloud Function for a cold request. When you're streaming LLM responses back to a user, 400ms of cold-start is a visible hiccup; 42ms is not.

What we actually store in Postgres on a typical client project: site content (a pages and blog_posts table, as we've written about in Supabase as a CMS), the CRM extension tables that hang off HubSpot, any custom embeddings for AI features, audit logs, and the configuration tables that drive our automations. Row Level Security policies on every table mean a multi-tenant build doesn't require a separate database per client.

Layer 2: Systems — Next.js, Vercel, and MCP as the integration fabric

Next.js is the framework. Vercel is where it lives. Almost every site we build is statically generated at build time, with a few dynamic routes and edge functions for anything that has to be real-time.

This is not a novel choice in 2026. The DEV Community's 2026 solopreneur-stack writeup describes Next.js + Supabase + Vercel as "what AI generators produce well, what scales without surprises, and what you can deploy in hours rather than days." The YC 2025-2026 consensus stack is Cursor for coding, Supabase or Firebase for backend, Vercel for deployment, Stripe for payments, OpenAI or Anthropic for LLM features. We're within that consensus by design — tools your AI coding assistant already understands are tools you ship faster with.

But two pieces of our systems layer are less common and worth naming:

Static builds over server-rendered CMS

We don't run WordPress. We don't run Webflow on anything we can help it. We don't run Sanity or Contentful as a front-end CMS either. Content lives in Postgres, the build process pulls it at deploy time, and the site that ships is pure static HTML and edge functions. The Vercel deploy triggers off a webhook from Supabase or from an AI assistant (more on that below).

Trade-off: content updates aren't instant — they require a redeploy. For most agency clients that's not a real cost; a build is 60 seconds and we can queue edits. For a news site it would be a bad choice. Know which you are.

MCP as the integration fabric

Every third-party tool that talks to our systems — HubSpot, Slack, Supabase itself, our content database, Gong, Box, Google Search Console, DataForSEO — connects through the Model Context Protocol. MCP is the open standard Anthropic shipped in late 2024 that is now the default way AI agents connect to external tools, databases, and APIs.

As of 2026, MCP is supported by every major AI framework and adopted by Microsoft, Anthropic, and dozens of tool providers. In practical terms: when I ask Claude to "find the last five blog posts we published and check their schema markup," Claude reaches through MCP into our Supabase tables, pulls the posts, and hands them back. No custom script, no Zapier intermediary, no paid connector.

If you take one recommendation from this post, take this: wire your agency's tools together through MCP before you build another automation. It changes what the human-in-the-loop experience feels like. Zaps and webhook chains still have their place, but MCP is the new default surface for agent-style work.

What happens when you eat your own stack: the client portal

The most convincing proof that a stack works is what you build on it for yourself. In late 2025 we built our own client management portal on top of this exact stack, and it has quietly become the spine of how we run every engagement.

The portal is three things fused into one interface:

• A feed of work-in-progress. Every active deliverable — a draft post, a design iteration, an automation flow, a code change — lands here first. Clients approve, request changes, or comment inline. No more email threads with version-5-final-v2 attachments. No more "did you see my reply from the 14th?"
• A reporting dashboard. The KPIs the client actually tracks, plus our SEO, paid, and automation performance data, pulled straight from Supabase through MCP-connected tools. The same dashboards we use to run the work are the ones the client sees — no curated PDF reports that hide the parts we don't want visible.
• Invoicing and project accounting. A clean, auditable record of what's billed, what's due, what's signed, tied to the deliverables above. Clients see exactly what they're paying for against exactly what's been done.

The meta point: the portal was built entirely on the stack above. Next.js on Vercel, Postgres on Supabase with Row Level Security isolating each client, Claude Code writing the majority of the code, MCP wiring every feature to every data source. And the portal is now itself part of the stack we ship — every new client engagement includes a portal instance from day one.

That's what a stack that works actually looks like. You don't just build on it. You extend it, and the extensions feed back into the stack itself.

Layer 3: Automation — Zapier, HubSpot workflows, and Supabase Edge Functions

We separate automation into three tiers by complexity, and each tier has a different tool. We also move work between tiers as it matures — which is where most small agencies get the layer wrong.

Simple cross-app flows go to Zapier. Someone fills out a form, that creates a HubSpot contact, that sends a Slack notification, that adds a row to a Google Sheet. Zapier's connector library is still the largest in the industry, its documentation is canonical, and almost every SaaS vendor ships a Zapier integration before they ship anything else. For a two-step "trigger this when that happens" flow, it's live in ten minutes and nobody on our team has to maintain it.

We tried n8n. It's respectable software — but the trade-off didn't land for our shape of work. Self-hosting added an uptime problem we didn't want, the community nodes were uneven, and the documentation is meaningfully thinner than Zapier's, which slowed every new integration down. When every hour at a small agency is either client work or sales, paying a Zapier subscription beats burning afternoons on self-hosted automation infrastructure.

The important caveat: we are steadily migrating mature Zaps into Supabase Edge Functions. Once a workflow becomes load-bearing — running daily, wired into billing, or touching client data — the per-operation cost of Zapier crosses over with what a direct API call costs in an Edge Function, and the Edge Function is faster, more observable, and owned by us. Our internal rule is the Zap-to-API ladder: new flow ships to Zapier first so we learn its shape in production; any flow still running thirty days later gets evaluated for promotion into an Edge Function. That sequence avoids the two common agency mistakes — over-engineering a flow before you know its real shape, and under-engineering a flow after you do.

CRM-native logic stays inside HubSpot. Lead scoring, lifecycle transitions, sequenced emails, sales-task creation. HubSpot's native workflow engine is mediocre but the cost of leaving it is that your CRM data and your automation logic diverge, and then you debug in two places. The rule: if the logic is about CRM state, it lives in HubSpot.

Anything custom — or anything promoted off the Zap-to-API ladder — is a Supabase Edge Function. Deno runtime, deploys in seconds, costs fractions of a cent per invocation. When we need an AI-powered endpoint, an MCP server, an internal API that classifies inbound leads, or a scheduled job that generates SEO reports, it's a Supabase Edge Function. This is also where we host the custom MCP servers that talk to DataForSEO and Google Search Console for the SEO work on this very site, and where most of what used to be Zapier multi-step flows now lives.

The automation layer is where most small agencies over-buy. Per 2026 industry data from Digital Third Coast, 68% of US small businesses now use AI regularly — up sharply from 48% in mid-2024 — and a significant share of them are stitching together three or four overlapping paid SaaS automation tools. If you're running an agency, one connector-rich tool (Zapier), one CRM-native engine, and a Deno runtime you can promote mature flows into is enough for 95% of what you'll encounter.

Layer 4: AI — Claude, the Anthropic Agent SDK, and picking the right model for the job

We are an AI-native agency, so the AI layer is load-bearing — but it's also the layer where most agencies get lost in model-zoo sprawl. Our rule is simple: one default model family (Anthropic Claude), one secondary (Google Gemini, but only for image generation and specific multimodal tasks), and a clear matrix of which Claude model handles what.

Which Claude model for which job

• Claude Sonnet 4.6 is the default. 95% of client work — drafting, editing, coding, research, reasoning on structured data — runs on Sonnet. It is the best balance of intelligence, speed, and cost in the Claude lineup.
• Claude Opus 4.6 comes out for the hardest work: architectural decisions, multi-hour agent loops where every step has to be right, legal-adjacent reasoning, strategic writing where the tone is load-bearing.
• Claude Haiku 4.5 handles the cheap high-volume loops: classification, extraction, simple summaries, pre-filtering before a more expensive model gets involved.

For image generation, we use the Gemini API, because at the time of writing Anthropic does not ship a first-party image generation endpoint. Our generator lives in a Supabase Edge Function with a fixed brand prefix that forces every output into our visual system (monochrome, single pop of color, pure white background) — a detail you can see in any hero image on this site.

Our philosophy on model choice: model zoo sprawl is a leading indicator of an agency that will underdeliver. Every additional model you use is another SDK, another pricing model, another failure mode, another prompt style to maintain. Pick one family, use it for 95% of the work, and only reach outside when the use case genuinely can't be served.

Why Claude specifically

Three reasons. First, Anthropic's tool-use and agentic behavior is — in our experience — the most reliable in 2026 for the kind of long-running, multi-step workflows an agency depends on. Second, Claude writes in a voice that is less detectable as "AI slop" than most alternatives, which matters when AI text is the substrate of your deliverable. We've written about that tendency in Why your AI chatbot sounds like everyone else's. Third, the Anthropic Agent SDK shipped in 2025 and has made multi-agent systems accessible without writing orchestration infrastructure from scratch — per DEV Community's 2026 AI-engineering roundup, this is a genuine productivity step-change.

One more data point: per multiple 2026 industry surveys, 72% of engineering teams now use at least one autonomous coding agent in their workflow, up from 31% in 2025. Claude Code is ours. It's the coding agent that writes most of the code that ships our client sites. A human — me — reviews every meaningful change. But the ratio of "code I write" to "code I approve" has flipped completely in 18 months.

Where the stack goes next: Claude Managed Agents

The biggest shift coming to our delivery model this year is Anthropic's rollout of Claude Managed Agents — long-running, hosted Claude agents that Anthropic versions, scales, and operates for you. We define the behavior, wire the agent to our MCP servers and to the client's data sources, and ship. No orchestration infrastructure we have to babysit. No cold-start problem. No nightly uptime concern.

This is disruptive for how an AI agency packages value. Until now, every AI feature we shipped a client was either a synchronous API call stitched into their app or a batch job running in a Supabase Edge Function. Managed Agents introduce a third shape: an always-on, conversational teammate the client can actually talk to, which has standing access to their tools through MCP and persistent memory across interactions.

We are actively incorporating Managed Agents into every tier of our offer: intake agents for law firms and consultancies, internal-operations agents that sit on top of HubSpot and Supabase, research agents with scoped MCP access to a client's data room, content-maintenance agents that run the kind of SEO and freshness work we do for Automaton itself. This post describes the stack as it runs today. Managed Agents are where the stack is going — and the bet underneath every other choice on this page (Postgres over NoSQL, MCP as the integration default, Claude as the default LLM) is the bet that makes that transition a software update on our side, not a rebuild.

Layer 5: Human strategy — the creative technologist at the top

Four technology layers sit under one person: a creative technologist. At Automaton that person is me. At a larger shop it's a small, deliberately over-leveled team.

This is the layer nobody else can clone.

Everything else in this post is copyable in an afternoon. Sign up for Supabase. Deploy to Vercel. Wire up MCP. Point Cursor at Claude. By tomorrow morning you have four-fifths of the Automaton stack sitting in a GitHub repo. Frontier models are a commodity — every agency in America gets the same Claude Sonnet we do, at the same price, on the same day. Vercel serves the same HTML to every agency that deploys there. The tools are a starting line. They are not a moat.

The moat is this layer. It is the taste that says "the client is wrong about what they need — here is the problem we should actually solve." It is the positioning instinct that picks the three words a brand should sound like and the thirty it should never use. It is the gut call to throw away an on-brief draft because it's competent and forgettable, and to ship the second one because it's a little dangerous. It is the willingness to say no to the deal that would pay this month but wreck the next six. It is knowing when the AI answer is 90% right and the remaining 10% is where the actual work lives.

Those calls are the product. Everything below this layer — Postgres, Next.js, Zapier, Claude, MCP — is leverage. This layer is the thing the leverage is applied to. A great stack under a mediocre creative technologist produces polished mediocrity faster. A great creative technologist with a mediocre stack still ships work people want to work with. The combination is rare, which is why agencies that actually have it command rates that make traditional agencies uncomfortable.

What specifically lives at this layer that can't be automated in 2026 (or shouldn't be):

• The client conversation where you figure out what the actual problem is — not the one in the brief
• The positioning call: what the brand should sound like and where it must not sound like anyone else
• The "we'd rather not take this project" call
• The trade-off call when two layers conflict — a client wants a CMS the stack doesn't natively support, or insists on a pattern the data model will punish them for in six months
• The taste call on a visual system, a tone of voice, a structural choice — the things that make the work look and feel like someone made it, not like something was generated
• The judgment about when to slow down and do a thing by hand because the AI answer is close enough to be seductive and wrong enough to be embarrassing
• The long conversation with a client about whether this is actually the quarter to ship the thing they think they want

The creative technologist does not just manage the stack. They are the reason the stack exists in its current shape. Swap in a different person with a different aesthetic and a different technical taste and the stack drifts to match — different defaults, different trade-offs, different output. The stack is downstream of the human at the top of it. That is the sentence the rest of the agency industry hasn't quite absorbed yet, and it's the sentence this post is really about.

What we deliberately don't use

A stack's shape is defined as much by what it excludes as what it includes. Our "no" list:

• WordPress. 40%+ of the web, great ecosystem, wrong default for a 2026 AI agency. Plugin sprawl, security maintenance, and the fact that it's a nightmare to feed to an AI coding agent all disqualify it.
• Salesforce. Overkill for the companies we serve. HubSpot is the right weight class.
• Firebase. Proprietary NoSQL, unpredictable billing, and the vector-search story is a Vertex AI stitch-up. Supabase wins on every axis that matters to us.
• Heavy headless CMSes. Sanity, Contentful, Strapi. Good products; wrong shape. Content is just Postgres tables plus a Claude-powered edit interface — see Supabase as a CMS.
• n8n. We gave it a serious look. Self-hosting adds an uptime problem we don't want on our plate, the community-contributed nodes are uneven, and the documentation is meaningfully thinner than Zapier's — which shows up every time you try to integrate a new tool. For a small agency, the math favors a paid Zapier seat over a weekend of babysitting a self-hosted automation server.
• Any no-code website builder for delivered client work. Wix, Squarespace, Webflow as a primary CMS. These are fine for the client to learn on; they are not what we deliver.

What it costs to run

For an agency of 1-3 people with 5-10 active client projects, the stack above comes in under $300 a month in platform fees at time of writing:

• Supabase Pro: $25/month base plus usage
• Vercel Pro: $20/month per seat
• Zapier Professional: ~$50-80/month depending on task volume (and trending down as we promote flows off the Zap-to-API ladder into Edge Functions)
• HubSpot Starter CRM Suite: $20/month per seat
• Anthropic API: variable (roughly $40-80/month for a single builder working heavily with Claude Code and agents)
• Gemini API for image generation: ~$5/month at our volume
• Cursor Pro for local development: $20/month

Compare that to a traditional agency stack — WordPress hosting, paid CMS seats, Salesforce, Pardot, Zapier Enterprise, Adobe Creative Cloud, and a tangle of hand-rolled PHP plugins — and the monthly fixed cost is 5-10x lower. That money moves where it belongs: into the humans doing the creative work, not into the toolkit they use.

How this compares to a traditional agency stack

The short version of our comparison piece: the traditional agency stack is optimized for handoffs between specialists. Designer to developer, developer to CMS admin, CMS admin to SEO specialist, SEO specialist to PPC specialist, PPC specialist to reporting analyst. Each layer needs its own tool because each specialist prefers their own tool. The stack's complexity reflects the org chart's complexity.

The AI agency stack is optimized for one generalist with AI assistance to do all of the above. There are fewer tools because there are fewer handoffs. The tools that remain are the ones that play well with AI — structured data, API-first, MCP-compatible, well-documented.

That is the single biggest trade-off hiding inside this post. Pick the AI agency stack and you are also picking a team shape: fewer people, higher capability per person, AI as leverage. The tools won't save a team that still wants to run like it's 2018.

Frequently asked questions

If you're building this out

If you're assembling your agency's stack for the first time and want an outside set of eyes — or you're running a traditional agency and want to understand what migrating to this posture actually looks like — we run a paid audit that covers all five layers. More at the revenue audit page.

And if you want more on the philosophy behind the stack, the closest companion pieces are What a creative technology agency actually does and AI agency vs traditional agency: why the comparison is wrong. The five-layer framework post is the architectural backbone all three share.