Development
The actual agency ai stack our team uses day-to-day in 2026 - tools, harnesses, custom MCPs, and honest opinions on what is overhyped and underhyped.
Every agency CTO I talk to in 2026 gets the same question from clients, prospects, and other founders: "What is your AI stack? What are you actually using?" The honest answer keeps shifting because the tools keep shifting, but the shape stabilized in the last six months. So this is a snapshot of what our team uses, what we tried and dropped, what we are about to add, and the opinions I have actually formed about what is overhyped and what is underhyped in the agency ai stack of 2026.
This is not the canonical "you should use these tools too" post. Stacks are personal and project-shaped. But every CTO benefits from seeing how someone else's looks, and most posts on this topic are vendor-flavored or marketing-flavored. This one is not.
Tools are not interesting in isolation. They are interesting in how they assemble. Here is ours, surface by surface.
The terminal is where most of our work now happens, especially anything that touches the codebase across more than one file. Claude Code's signature appeared on 4% of March 2026 GitHub pushes and the Pragmatic Engineer's February 2026 survey put it on top for "tool I would fight to keep" at 46% most-loved. That tracks with our experience.
What it is good at:
CLAUDE.md files for per-project context. We have one in every active project; they are the difference between "useful" and "magical."What it is bad at:
We use Cursor for the inline editing work where Claude Code's terminal flow is wrong. Tab completion, small inline refactors, "explain this function," "convert this React class to a hook." Cursor is used by 67% of the Fortune 500 generating 150 million lines of enterprise code daily - the IDE-bound model is the right model for a lot of work.
The two modes coexist well. Claude Code for the terminal-shaped work, Cursor for the editor-shaped work. We do not pick one; we pick by task.
For first-pass UI, especially marketing pages and dashboard layouts, v0 has gotten close enough to "show it to the client tomorrow" that it has changed our delivery rhythm. The pattern: prompt v0 for the rough shape, paste the output into our Shadcn-based design system, refine the tokens and spacing manually.
Lovable has its place for full-app prototypes, especially for non-technical founders we are doing discovery with. It is faster than Figma for "let me see what this idea looks like as a working app."
What we do not use v0 for: production-ready code. The output is a starting point, not a finished surface. The Cursor or Claude Code pass after v0 is what makes it shippable.
The single highest-leverage shift in 2026 was MCP becoming the standard. Our daily stack now includes:
The custom MCPs are the underhyped move of 2026. Every client engagement now starts with "what are the three systems your team checks 20 times a day, and can we expose them via MCP?" The answer is almost always yes, and the productivity unlock for the client team is immediate.
For client engagements that need voice agents (sales follow-up, appointment scheduling, intake), we use our own product, CallFlowLabs. (Disclosure: it is a DesignKey product.) The architectural pattern there is the same one we use for chat agents - workflows first, MCP for tool use, human handoff at the right altitude.
Tools are interchangeable. The harness around them is what makes a team 3x rather than 1.2x. Our harness, in rough order of impact:
Reusable units of capability that show up in Claude Code and Cursor. Things like commit-git, branch-git, frontend-design, geo-optimization, chrome-devtools for browser debugging. Each one bundles a prompt, a set of tools, and a mental model into a single trigger.
We maintain a shared skills repo across the team. New skills get reviewed in PR like code. The discipline matters; the failure mode is everyone inventing their own one-off skill that the rest of the team never sees.
The harness automation. Hooks fire on events (SessionStart, UserPromptSubmit, SessionEnd, PreToolUse, PostToolUse) and let us bake organizational policy into the runtime. Our active hooks:
claude -p summarization on exit.git push --force to main without explicit confirmation.Hooks are the difference between "AI tool that happens to run on my laptop" and "AI tool that knows my organization." Worth the up-front investment.
Specialized agents with their own instructions, tools, and personas. We have a seo-expert agent, a marketing-expert agent, and a few client-specific ones. These are not models; they are configured Claude instances with bespoke prompts and bespoke tool access.
The pattern: when a category of work shows up enough times that we are repeating the same setup ("act as our SEO expert, here is the brand voice, here is the keyword strategy, here are the existing posts"), we factor it out into a custom agent.
Every active project has a CLAUDE.md at the repo root. It tells the agent the project's conventions, the tech stack, the deployment surface, the do-not-touch areas, the preferred patterns. New engineers are told to read it; agents read it automatically.
The discipline of writing CLAUDE.md changes how we think about projects. If you cannot describe a project's conventions in one document, the project does not have conventions.
We covered the broader engineering team economics in The Economics of an AI-Augmented Engineering Team and the team structure shifts in AI-First Engineering Team Roles.
The biggest shifts since mid-2025, in rough order of impact on our day-to-day:
1. MCP went from interesting to default. A year ago, you wrote custom integrations for every tool. Today, you check whether an MCP server exists first, and you write one if not. The 10,000+ public servers and 97M monthly SDK downloads tell you the inflection happened.
2. Claude Code became the terminal default. A year ago, terminal-shaped agents were a research project. Today, they are how a meaningful percentage of our team's code gets written.
3. The "designer who codes" hybrid became real. With Cursor, Claude Code, and v0, our designers are shipping production PRs for design system tweaks, content updates, and typography changes. The old "throw it over the wall to engineering" pattern is dying.
4. Eval discipline became table stakes. Two years ago, "we have an eval set" was a differentiator. Today, it is the floor for any AI feature that ships to customers. We covered this discipline in Testing AI Features With Golden Sets.
5. Claude Code, Cursor, and Codex started converging. The interesting thing is not that they compete; it is that teams now run all three together, each for what it is best at. The "one tool to rule them all" expectation has dissolved.
Three predictions I am willing to defend in 2026:
1. Long-running agents become real. The Anthropic Managed Agents launch in April 2026 was the inflection. Agents that run for hours, persist state via /mnt/memory/, and survive across sessions are about to be table stakes. The use cases that need this (long-running research, multi-day workflow execution) are unblocked.
2. Storybook-aware coding agents. The next leap in frontend AI is agents that can read your Storybook, understand your component contracts, and refactor with that context. Today's agents grep for components; tomorrow's will query the design system as a structured surface. We covered the design system foundation in Design Systems 101: When Your SaaS Needs One and the Storybook for Designers guide.
3. "Design agents" that edit Figma directly. Plugins that talk to Figma via MCP exist; the first generation of "edit my design system tokens via natural language" tools shipped in early 2026. By year-end this becomes a normal designer workflow.
What I am willing to be wrong about, but I do not think I am.
The single most overhyped pattern of 2026. Every framework demo shows a "supervisor agent" coordinating four "specialist agents" producing a beautiful result. In production, the same workflow:
Almost every multi-agent demo I have seen would ship faster, cheaper, and more reliably as a workflow with one or two LLM calls. Anthropic's "Building Effective Agents" guidance still holds: workflows first, agents only when justified, multi-agent only when the alternative is genuinely worse.
The exception: orchestrator-and-workers pattern with bounded sub-tasks (the orchestrator hands a single, well-defined sub-task to a worker, the worker returns a structured result, the orchestrator integrates). That works. Peer-to-peer agent chatter does not.
The single highest-leverage move of the year for us. Three days of engineering effort to expose a client's existing system via MCP, and the client's whole team can now use Claude with their actual data. We have written more custom MCP servers in the last six months than we have written REST APIs.
The MCP ecosystem benefits from the asymmetry: the marginal cost of a new server is days; the cumulative benefit is every agent the client will ever use against that data. This is the closest thing to a free lunch in the 2026 stack.
Browsers that "use the web on your behalf" via screen-scraping and computer-use models. Operator's documented brittleness on UI changes is the canonical example. The screen-scraping pattern is the wrong abstraction. The right abstraction is APIs and MCP servers, where the data is structured and the contracts are explicit.
Will the agentic-browser pattern eventually work? Maybe. Will it work in 2026 production for any non-trivial workflow? No.
The boring economic unlock that more teams should use. Anthropic's prompt caching cuts input cost by up to 90% on cached tokens. For any system with stable system prompts and tool descriptions, prompt caching pays for itself immediately. We have not built a serious agent in 2026 without it.
Every long-lived agent in our codebase is simpler than its first version. We delete more code in our agents than we add. The temptation to add a sub-agent, a memory layer, a routing matrix is constant. Resisting it is the discipline.
The 2026 agent that ships and survives is the boring one with a clear control flow, a small set of tools, a strict eval set, and obvious failure modes. Not the agent with seven sub-agents, three vector databases, and a custom orchestration framework.
If you are an agency CTO or founder trying to assemble your own version of this, the working order:
For the broader picture on what AI integration looks like for clients, AI Integration for Business: The 2026 Practitioner's Guide is the pillar piece. For the engineering team economics, The Economics of an AI-Augmented Engineering Team. For the cost question, How Much Does AI Integration Cost in 2026?.
The thing that surprised me most in 2026 is how much of the leverage lives in the harness, not the tools. The tools matter; everyone has access to the same tools. The harness is what makes a team 3x rather than 1.2x. That is the part worth investing in. We help clients build their own version of this as part of AI Integration and Software Development engagements when the project is big enough to warrant it.
Want a second opinion on your team's AI stack? Contact us for a free 30-minute consultation.
Go deeper
Agents that worked great in demos die in production for the same reason: their memory is wrong. Here is the working 2026 model for ai agent memory management - three layers, four patterns, and the Anthropic code-execution trick that cut one canonical workload by 98.7%.
A technically flawless app that solves the wrong problem is still a failure. The problem-solution fit framework helps teams validate they are building something users actually need - before a single line of production code is written. Here is how to apply it.
Most teams think user-centered design means having a UX designer on the project. It actually means restructuring how discovery, planning, and development work - so that user evidence drives decisions at every stage, not just during wireframing.
Whether it's an internal tool for your company or a highly available Software-as-a-Service - we help you to get your ideas off the ground!