Forem: Gnanaguru Sattanathan

Your MCP Client Just Got Superpowers: Arcade Tools are now in Cursor, VS Code, and more

Gnanaguru Sattanathan — Thu, 26 Feb 2026 08:00:00 +0000

If you've been using Cursor, Claude Desktop*, VS Code, or any MCP-compatible client, you've probably experienced the same frustration: your agent is brilliant at reasoning through workflows, but the moment it needs to actually do something across your tools, you're back to juggling configurations for each individual tool, debugging auth flows, and troubleshooting why the setup that worked yesterday doesn't work today.

Those days are over. With the launch of Arcade MCP Gateways, your MCP client of choice can now instantly connect to Arcade's catalog of best-in-class tools as a single collection so you get agents that can actually take actions with full authorization and better accuracy, for any use case you need. As a single URL, your agents can access a curated set of use case specific tools, work across any MCP client, and be shared with your entire team in seconds.

The Pain You Already Know

Every developer who's tried to build real workflows with MCP tools has hit the same walls:

Fragmented tooling. You need GitHub, Linear, Slack, and maybe your CRM. That's four different MCP servers, each with its own configuration, its own auth flow, its own quirks. Some are official, some are community-maintained, some break when you look at them wrong.

IDE lock-in. You painstakingly configure everything in Cursor. Then you want to try Claude Desktop* or the new VS Code MCP support. Time to start from scratch.

Team friction. Your workflow is finally working. Now you need to onboard three teammates. That means writing documentation, walking them through auth, debugging why it works on your machine but not theirs.

Zero visibility. Something went wrong. Which tool failed? What permissions are missing? You're flying blind.

These aren't edge cases. This is the default experience for anyone trying to build agent-driven workflows today.

What MCP Gateways Now Enable

An Arcade MCP Gateway is a single URL that exposes a curated set of tools through one consistent interface. What does this unlock?

Access the largest catalog of high-quality tools

Most MCP servers you'll find are minimal wrappers around REST APIs. They expose raw endpoints, return inconsistent schemas, and leave error handling as an exercise for the model. APIs were designed for structured inputs from applications, not the natural language intent that comes from agents. The result: poor accuracy, frustrated users, and workflows that break unpredictably.

Arcade has developed thousands of agent-optimized MCP tools, including GitHub, Linear, Slack, Salesforce, Google Workspace, and many other integrations. These aren't wrappers. They're purpose-built for agents:

Consistent schemas across all integrations so agents can reason about tools predictably
Predictable error handling that agents can understand and recover from
Semantic tool design where operations map to what agents actually want to do, not just what the underlying API exposes

So now you can build any agentic workflow that can not only connect to all the systems you care about, but can take actions on them with better reliability and lower costs.

One URL, All Your Tools

Instead of configuring multiple MCP servers, you select the tools you need—GitHub, Linear, Slack, Gmail, whatever your workflow requires—and Arcade bundles them into a Gateway. You get one URL that provides access to all of them.

https://api.arcade.dev/mcp/gateway/your-gateway-id

Point your MCP client at this URL. Done.

And if you have your own MCP servers? Bring them. Arcade's Gateway can aggregate tools from any source — Arcade's catalog, your custom servers, third-party MCP implementations — behind a single endpoint.

Portability Across Clients

The same Gateway URL works in Cursor, Claude Desktop*, VS Code, ChatGPT, and any other MCP-compatible client. Configure your tools once, use them everywhere.

Want to try that new IDE everyone's talking about? Your Gateway comes with you.

Multi-User by Default

Most MCP setups are fundamentally single-user. They work great on your machine, but scaling to a team means everyone manages their own tokens and their own configs. This is why so many agent projects never get past the demo stage.

Arcade MCP Gateways are multi-user from the start. Send a teammate the Gateway URL. They authenticate with their own credentials for each service — their Google account, their GitHub identity — and they're running the same toolset you are. Same tools, same reliability, their permissions.

The security context travels with the user, not the agent. That's what makes this actually deployable in a team environment.

Visibility Into What's Running

Gateways give you a single place to see what tools are available, what's been called, and what's happening across your integrations. No more black-box debugging.

Getting Started with MCP Gateways: Agentic Developer Workflow example

Let's walk through what this can look like for a common developer workflow.

Every engineer runs this loop on repeat: grab a ticket from Linear, create a branch in GitHub, make your changes, open a PR, assign reviewers, close the ticket, and notify the team in Slack. Your agent already helps you code. With an Arcade Gateway, it can handle the rest too.

Tools needed: GitHub, Linear, Slack

Step 1: Create Your Gateway

Head to the Arcade Dashboard and create a new Gateway. Add these tools:

GitHub — for branches, commits, and PRs
Linear — for ticket management
Slack — for team notifications

Within each Gateway, you pick exactly which tools to expose to your agent. This is where centralized governance happens—you decide which Gateway (and which team or use case) gets access to which tools. Three tools, one Gateway, one URL.

Step 2: Connect Your MCP Client

Add your Gateway URL to Cursor Settings -> Tools & MCP:

{
  "mcpServers": {
    "ARCADE-MCP": {
      "url": "https://api.arcade.dev/mcp/engineering",
      "headers": {
        "Authorization": "Bearer arc_xxxxxxx",
        "Arcade-User-ID": "john@acme.com"
      }
    }
  }
}

Your agent now has access to GitHub, Linear, and Slack through a single connection.

Step 3: Authenticate

When your agent tries to access a tool it doesn't have permission for yet, Arcade detects this and prompts you to authorize just-in-time, with exactly the scopes needed for that action. No upfront permission grabs, no over-provisioning. You authorize what's needed, when it's needed.

These are first-party OAuth flows directly with each provider: GitHub, Linear, Slack — the same flows your security team already trusts. Once authorized, Arcade handles token refresh and lifecycle automatically.

Step 4: Run the Workflow

Open Cursor and tell your agent:

"Pick up SAL-20 from Linear, create a feature branch in GitHub Repo - https://github.com/ArcadeAI/F1-Pitwall. When I'm done with my changes, open a PR with a description based on the ticket, assign @evan as reviewer, close the Linear issue, and post an update to #engineering in Slack."

Watch it happen. Your agent grabs the ticket, creates the branch, waits for you to code, opens the PR, updates Linear, and notifies the team — all without leaving your IDE.

See It in Action

MCP Gateways for any use case or user

Different teams need different tools. Your engineering team needs GitHub and Linear. Support needs Zendesk and Confluence. Sales needs Salesforce and HubSpot.

You can create separate Gateways for each use case, each with its own curated toolset. Each Gateway becomes a managed endpoint for the specific workflow or team. Here's an example of what becomes possible when your agent has reliable tools behind a single Gateway.

Persona	Tools	Example Prompt
Developer	GitHub, Linear, Slack	"Pick up PROJ-1234, create a branch, and when I'm done, open a PR and close the ticket."
Engineering Manager	Linear, Jira, GitHub, Slack	"What did the platform team ship this week? Any blocked issues?"
Incident Response	PagerDuty, GitHub, Confluence, Slack	"What changed in the payments service in the last 24 hours? Any related customer tickets?"
Customer Support	Zendesk, Salesforce, Confluence, Slack	"Pull up context for ticket #45231 and check if this customer has had similar issues before."

Each persona gets a Gateway with exactly the tools they need. Different permission structures, same reliability. The developer workflow is the one most teams start with—issue to branch to PR to done, all from your IDE.

The Bigger Picture: Managing MCP Gateways at Scale

Here's where it gets interesting for platform teams and Arcade admins.

Arcade functions as a single runtime for all your MCP tools — whether they're from Arcade's catalog, custom-built, or third-party servers you bring yourself. Every Gateway is a single, manageable URL that plugs into this runtime.

Centralized governance. You decide which tools are available in which Gateway, with granular permissions. Engineering gets GitHub and Linear. Support gets Zendesk. Sales gets Salesforce. Each team has exactly the tools they need, nothing more. No MCP sprawl, no teams accidentally rebuilding servers that already exist.

Non-disruptive updates. Your team switches from ClickUp to Linear. In the old world, everyone reconfigures their local MCP setup. With Gateways, you update the Gateway once. Everyone using that Gateway URL gets the new tools automatically. Version control and safe rollouts built in.

Fine-grained audit logs. See what tools are being used, by which user, for which actions, across which services. This isn't just useful for debugging. It's the visibility your security team needs to actually approve agent deployments. OTEL-compatible for integration with your existing observability stack.

Scalable onboarding. New hire joins the team. Send them the Gateway URL. They authenticate with their own credentials. Done. They have the same toolset as everyone else, with their own permissions.

This is the shift: from "every developer manages their own MCP configuration" to "the platform team manages Gateways, any team can just use them." You get to accelerate AI development without sacrificing the control enterprise environments require.

Resources

Try It Free

MCP Gateways are now available as part of Arcade's runtime. Create a Gateway, connect your client, and see what your agent can actually do when it has reliable tools behind it.

Get Started for free →

Have questions or want to share what you're building? Join the conversation on Discord or reach out at hello@arcade.dev.

*Claude Desktop will be coming soon

Federation Over Embeddings: Let AI Agents Query Data Where It Lives

Gnanaguru Sattanathan — Thu, 26 Feb 2026 08:00:00 +0000

Someone told you to pivot to AI. Add an AI layer. "We need to be AI-first."

Fair enough. So you start thinking: what does AI need? Data. Obviously.

So the playbook writes itself: collect data in a central place, set up a vector database, do some chunking, build a RAG pipeline, maybe fine-tune a model. Then query it. Ship the chatbot. Declare victory.

This is what I call the AI centralization tax. Not the cost of having a data warehouse — that's often justified. The tax is building a parallel AI-specific data infrastructure on top of what you already have: vector databases, embedding pipelines, chunking strategies, custom models. A whole new layer, just for AI.

Here's the thing: you might eventually need some of that. But probably not yet. And probably not for the use cases you think.

You likely already have systems that hold your data: CRMs, support platforms, billing systems, maybe a data warehouse. The question isn't whether to centralize data (you probably already have). The question is whether AI needs its own separate copy, transformed into embeddings, stored in yet another database.

The answer is almost always no.

If you're going after differentiation, if you're trying to prove unit economics, if you're racing to stay ahead of competitors — building AI-specific infrastructure before seeing any returns is a strategic mistake. You're creating a parallel data estate for questions you haven't validated.

And here's the trap: once you've invested months building embedding pipelines and vector infrastructure, it's painful to pivot even when better options emerge. That's not just technical debt. That's strategic lock-in to an architecture that may already be obsolete.

Let's Be Blunt

Someone asks: "What's the health of this customer?"

You don't need a RAG pipeline for that. You don't need a vector database. You don't need your own model. You don't need a data warehouse with months of ETL work.

What you need: an AI agent with tool calling capabilities and a capable foundation model. That's it. Everything else is optimization.

An agentic AI system with tool access can query your CRM, pull recent support tickets, check billing status, and synthesize a health assessment in seconds — with real-time data, without any infrastructure you need to build or maintain.

This isn't theoretical. This is what's possible right now with MCP (Model Context Protocol) and Agent orchestration frameworks.

If your AI use case looks anything like "get me information about X from our systems," stop. Don't reach for the centralization playbook. There's a faster path.

The AI Centralization Playbook

Four approaches, same trap: building AI-specific infrastructure instead of leveraging what you have:

RAG pipelines. Chunk your documents, generate embeddings, store them in a vector database, retrieve the top-k matches, stuff them into context. Works for "chat with your PDF." Falls apart when you need accurate structured results — ask for a count or an aggregation and you get hallucinated numbers. Teams keep optimizing chunking strategies and similarity thresholds, solving the wrong problem.

Custom fine-tuned models. Collect training data, curate examples, run fine-tuning jobs, deploy, monitor drift. Weeks or months of work. By the time you ship, base models have improved and your fine-tune is already behind.

Data warehouses for AI. You already have Snowflake or BigQuery for analytics. The AI playbook says: now build semantic layers, create AI-specific transformations, maybe replicate into a vector store. More infrastructure, more maintenance, when an AI agent could just query your existing warehouse directly via tool calling.

Knowledge graphs for AI. Model your domain as entities and relationships, ingest data, build traversal logic. Months of work, brittle when schemas change, solving a problem that agentic systems with tools can often handle through reasoning.

Same pattern: assume AI needs its own data layer. Same problem: you're building parallel infrastructure instead of connecting to what exists.

Federation: The RAG Alternative That Ships

There's a simpler question: why does AI need its own copy of the data?

If AI agents can reason, and tools can query systems, and LLMs can synthesize — the data can stay where it already lives. Query at runtime. Synthesize on demand.

That's federation. Instead of copying data into AI-specific infrastructure, give agents tools to query your existing systems directly.

Critical clarification: A Snowflake warehouse with an MCP server is federation. You're querying data where it lives. The warehouse serves its purpose, and AI agents access it directly without needing a vector layer on top. Federation isn't anti-warehouse — it's anti-duplication.

What makes this viable now:

Model capability. Frontier LLMs handle multi-step reasoning and tool orchestration reliably. Context windows hold results from multiple system queries. The models do synthesis that would have required custom code two years ago.

Tool standardization via MCP. The Model Context Protocol has emerged as the standard for connecting AI agents to external systems. Major model providers — Anthropic, OpenAI — have adopted it. The ecosystem now includes thousands of pre-built integrations: CRMs, support systems, billing platforms, databases, developer tools. And there are MCP runtimes that handle authorization at query time — agents authenticate as the user rather than relying on over-privileged service accounts.

Agent frameworks. The orchestration layer has matured. Chain-of-thought reasoning means agents recover from mistakes and converge on correct answers. Error handling that required explicit coding is now emergent behavior.

Three AI Agent Architecture Patterns

Each pattern builds on the previous one. Start simple, add complexity only when you hit limits.

Pattern 1: Simple Federation with Tool Calling

The foundational pattern. An AI agent receives a query, uses tool calling to query source systems via MCP servers, and synthesizes the answer.

Don't underestimate this. With current LLMs, simple federation handles most "get me information about X" queries — status checks, lookups, cross-system research — without any custom infrastructure.

The key insight: the agent is the join layer. It reasons across sources, handles schema differences through semantic understanding, and synthesizes coherent answers. You don't need to model the relationships in advance — the agent figures them out at query time.

How it works: The agent maintains minimal state — just enough to track the conversation and coordinate MCP tool calls. Each query hits source systems directly, gets fresh data, returns results. Agent frameworks like LangGraph provide state persistence and checkpointing out of the box — this alone takes you a long way.

Works for: Status checks, lookups, cross-system queries, research tasks. "What's the health of Acme Corp?" "Show me recent tickets for this customer." "What's our pipeline this quarter?" "Compare this customer's support history with their billing status."

Limitations: Adds latency (typically 2-5 seconds for multi-system queries, on top of model inference time). No persistent memory across sessions — as more tools and systems are queried within a session, context grows and accuracy can degrade.

When it breaks: Queries requiring computation across large datasets (aggregations over thousands of records), sub-second response requirements, or queries where source API latency compounds unacceptably.

Pattern 2: Federation with Ephemeral Compute

Simple federation handles most queries. But some tasks need more: complex aggregations, data transformations, joins across large result sets, or generating artifacts from fetched data.

For these cases, add ephemeral compute.

How it works: The AI agent fetches data via MCP tools, then spins up temporary compute — a sandboxed environment where it can execute code, run SQL against in-memory databases, or process data programmatically. Results return, compute disposes. Sandboxed environments like E2B are built specifically for this pattern.

Works for: Cross-system joins over thousands of records, complex aggregations, code generation from data, document assembly, analytical scripts.

Limitations: More complex orchestration. Adds latency (compute spin-up plus execution time). The join logic itself can be complex when schemas don't align — you're writing fuzzy matching or asking the agent to reason about entity resolution.

When it breaks: Datasets exceeding what fits in memory (typically 100K+ records depending on schema width), queries requiring historical data the source systems don't retain, or when you need results cached for repeated access.

Pattern 3: Agentic AI with Long-term Memory

Add persistent context that accumulates across sessions. The AI agent federates for current data but also maintains memory of decisions, context, and precedents.

How it works: Before querying live systems, the agent checks memory for relevant history. This isn't about embedding your entire data estate — it's about persisting agent-generated context: decisions made, precedents set, user preferences learned. Memory layers like Mem0 and Zep are emerging to solve this.

The difference from traditional RAG: You're storing agent-generated context, not raw source documents. It's accumulated intelligence from interactions, not replicated data. The memory is append-only and grows organically from actual usage.

Works for: Decision support with precedent ("Should we approve this discount? What did we do for similar deals?"), personalized experiences that improve over time, audit trails of agent reasoning.

Limitations: Memory architecture is still maturing across the ecosystem. You need explicit decisions about what's worth persisting. Memory retrieval adds latency and can surface irrelevant context.

What About the Edge Cases?

"What about schema mismatches?" When Salesforce's "Account" doesn't match Stripe's "Customer" — that's a SQL problem, not a vector problem. An AI agent with schema context can write joins that handle naming conventions and fuzzy matching. You need a capable model and well-designed MCP tools, not embeddings.

"What about finding similar customers?" Before reaching for vector similarity, ask: can SQL pattern matching, joins, and filtering get you there? Most "similarity" use cases are structural, not semantic. Agent reasoning with tools can get you there.

"What about latency and API costs?" Yes, LLM inference costs money. Compare that to three months of infrastructure investment before you've validated whether the use case matters. The model cost is the cheaper way to learn.

When you genuinely need vector search: Semantic search over large unstructured document sets where keyword search fails. That's RAG's sweet spot. Build it as an isolated tool: a vector store exposed via MCP, not as a centralized AI data layer.

The pattern: solve isolated problems with isolated tools.

The Asymmetry That Matters

You might eventually need a vector store for semantic search over documents. You might need a fine-tuned model for domain-specific language. You might need embeddings for true similarity matching at scale.

But you don't have to build any of that to start delivering value.

That's the asymmetry. You can always add AI-specific infrastructure later: vector stores, custom models, embedding pipelines — for the isolated use cases that genuinely require them. The tools-first architecture accommodates it. Build the vector store when you've proven you need semantic search. Fine-tune a model when base models demonstrably fall short.

You cannot easily do the reverse. Once you've invested months in embedding pipelines and vector infrastructure, you have teams maintaining them and stakeholders defending the investment. Pivoting to simpler tool-based approaches means stranded infrastructure and difficult conversations about sunk costs.

Start with MCP tools. Ship value in days. Add complexity only where it's earned.

If you start with the AI centralization playbook? By the time you've built the embedding pipelines and shipped the vector infrastructure, competitors who started with tools are on their third iteration. They've validated what users actually want. They're capturing market share while you're debugging retrieval accuracy.

The Bottom Line

Your data already lives somewhere: CRMs, support platforms, billing systems, data warehouses. AI agents with MCP tools can query those systems directly and synthesize answers in seconds.

Schema mismatches? An agent with context can reason through them. Cross-system joins? Ephemeral compute. Similarity search? Often just SQL pattern matching. Semantic search over unstructured documents? That's where a vector store earns its place — as one MCP tool among many, not as the foundation of your architecture.

The pattern I keep seeing work: start with federation, ship value quickly, then add specialized infrastructure only for the specific problems that genuinely require it. Vector stores, custom models, embedding pipelines — they all have their place. But that place is usually narrower than the default playbook suggests.

Most enterprise AI use cases are variations of "get me information about X from our systems." For that, agents and tools are enough. The organizations shipping fastest have figured this out.

Query data where it lives. Add complexity only where it's earned.

Patterns for Agentic Tools: Your agents are only as good as your tools

Gnanaguru Sattanathan — Wed, 25 Feb 2026 23:28:18 +0000

The Moment

Every few years, a new pattern language emerges that changes how we build software.

In 1994, the Gang of Four gave us Design Patterns. In 2003, Hohpe and Woolf gave us Enterprise Integration Patterns. Since then: Microservices Patterns, Cloud Patterns, and now Agent Patterns.

But there's a gap. Agents can chat and reason on their own — but they can't 'act' without tools. Standards like MCP have unlocked how agents discover and call tools. The protocol layer is solved. What's missing is the design layer: patterns for building tools that agents can actually use well. That's the missing layer.

What We Learned

We've built over 8000 tools across 100+ integrations — the largest catalog of agent-ready tools in production. Not API wrappers. Production-grade tools that handle the edge cases: rate limits, pagination, auth refresh, partial failures.

Every mistake you can make: unclear descriptions, unhelpful errors, parameters that made sense to us but not to an LLM, we've made it. We learned that "working" isn't the same as "agent-usable."

A tool can return the right data and still fail because the agent couldn't figure out when to call it.

After thousands of iterations, patterns emerged. We built internal checklists, review processes, and eventually a framework that let us ship quality tools consistently. Not theory — just what works when you're building tools that agents actually use.

We documented them. Now we're sharing them. Explore the full catalog at arcade.dev/patterns.

The Paradigm Shift

For two decades, we built integration around a simple model: middleware orchestrates, applications consume. ESBs routed messages. Workflow engines enforced sequence. The integration layer decided what happened, when, and in what order.

Agent tooling collapses that entire layer. There is no bus. There is no predetermined workflow. The agent decides which tool to call, interprets the parameters, handles the response, and figures out what to do next. The orchestration logic that lived in your middleware is now emergent, reconstructed by the agent on every invocation, with no guarantee it plays out the same way twice.

This isn't traditional integration with a new consumer. It's an entirely new type of consumer and the fundamentals have changed.

When an LLM selects which tool to call, interprets parameters, and decides what to do with errors, the design constraints are fundamentally different. The old patterns don't fit. We need new ones.

So where do you start? With a way to classify what you're building.

Three Axes of Classification

Every tool exists somewhere in three dimensions. Understanding where helps you pick the right patterns.

Maturity is the vertical axis: how sophisticated your tool is. Atomic tools do one thing: get_user(id). Orchestrated tools coordinate many, managing state across calls. We'll dig deeper into this axis in the maturity model below.

Integration is what your tool connects to — APIs, databases, file systems, or system operations. Each carries different design constraints. Database tools need the Idempotent Operation pattern because agents retry on timeout and your tool must handle duplicate calls gracefully.

Access is how execution works. Synchronous tools are straightforward: call, wait, respond. But a report generation tool that blocks for 45 seconds will timeout or stall the agent. That's where the Async Job pattern comes in: the agent calls generate_report(), receives a job ID, and polls check_status(job_id) until complete.

Your coordinates across all three axes determine which patterns you need. A tool that is Composite × Database × Async has very different design requirements than one that is Atomic × API × Sync.

Cross-Cutting Concerns

Knowing where your tool sits on the three axes tells you which patterns to look at. But four concerns cut across every axis: agent experience, security boundaries, error-guided recovery, and tool composition. Get these wrong and it doesn't matter how well you've classified your tool.

Agent Experience

Design for the LLM, not the human. Tool descriptions, parameter names, and error messages should be optimized for agent comprehension.

The Parameter Coercion pattern is a good example: an agent might pass "2024–01–15", "January 15", or "yesterday" — your tool accepts all of them and normalizes internally.

Security Boundaries

Prompts express intent, code enforces rules. Never trust the agent to enforce security. Authorization and secrets must be handled server-side.

The Context Injection pattern passes user identity, permissions, and credentials through a server-side context object — never through the LLM.

Error-Guided Recovery

Errors should teach, not just fail. When things go wrong, provide actionable guidance. What should the agent try next? A raw 429 means nothing to an LLM. A response that says "rate limited, retry after 30 seconds or reduce batch size to 50" gives the agent a path forward.

Tool Composition

Tools should compose well together like Unix pipes, not like a chain of command. That means consistent response shapes so one tool's output feeds cleanly as another's input, batch support so agents don't loop one-at-a-time, and multiple abstraction levels so the agent picks the right granularity for the task.

The Landscape: 54 Patterns, 10 Categories

These four principles — agent experience, security boundaries, error-guided recovery, and tool composition — thread through everything. They show up differently depending on the tool, but the questions they raise are universal: How will agents understand this? How do we keep it secure? What happens when it fails? How do tools fit together without directing each other?

We organized our answers into 54 patterns across 10 categories. Each category maps to one of those recurring questions:

Each pattern includes the problem it solves, when to apply it, implementation considerations, and code examples.

The full catalog is at arcade.dev/patterns.

Now how do you actually put it to use?

Building Your First Tool

Where you start depends on two things: where your tool sits on the three axes, and what maturity level you're at today.

Classify Your Tool

Work through four questions: What type is this — Query, Command, or Discovery? What integration — API, Database, File System, or System? What access pattern — sync, async, streaming, or event-driven? And what maturity level — single operation or bundled workflow?

Find Your Level

Your position on the maturity axis tells you which patterns to start with. Don't over-engineer: start atomic, watch how agents actually use your tools, and level up when you see the signals in your traces.

The observable signals between levels are real things you'll find in your logs: high retry rates mean your tool needs better descriptions and error guidance. Repeated tool sequences mean it's time to bundle. Partial completions on multi-step operations mean you need transaction boundaries and compensation.

Join Us

These patterns exist because of the engineering discipline behind them. The Arcade engineering team, particularly Eric, Renato, and Francisco, authored thousands of tools and built the quality control processes that turned hard-won lessons into repeatable standards.

This work is dedicated to them, to the broader tool engineering and MCP community, and to every team that's learned the hard way that "working" and "agent-usable" aren't the same thing.

The full set of patterns is at arcade.dev/patterns. Each pattern includes diagrams, code examples, and implementation considerations.

We're releasing these patterns openly because better tools benefit everyone. When the ecosystem builds better tools, agents get more capable. When agents get more capable, more people build with them. That's the future we want to help create.

What did we miss? What patterns have you discovered that aren't here? Where did we get it wrong? We'd love your feedback — send us a note, tell us what doesn't make sense.

This is a shared language. Help us make tools better.

Explore the full pattern catalog.
All 54 patterns with examples, trade-offs, and implementation guidance: arcade.dev/patterns

Ready to build?
Arcade gives you the runtime, the tools, and the auth layer to ship agents that actually work in production. Get started

Java's Agentic Framework Boom is a Code Smell

Gnanaguru Sattanathan — Sun, 02 Nov 2025 16:08:25 +0000

Originally published here

Last week, I published a post arguing that you don't need an agentic framework to start building agents. That piece was for the developers waiting on the sidelines for the "perfect" framework to arrive.

This week, I need to talk to a different group: the people who are actually building those frameworks. I know this group well because I was one of them.

I need to come clean. I'm a framework-aholic. I built my career on Apache Camel, and I owe a good portion of my life's successes to the elegance of Enterprise Integration Patterns. I get it. And if there's one community that deserves the Nobel Prize for Frameworks, it's the Java community. From the early days at Red Hat to the entire big data ecosystem, frameworks have been the engine of the JVM world for 15 years. We are the masters of abstraction.

So when the agentic era dawned and Java was playing catch-up, my first instinct was primal: build a framework. I even started one, driven by the thought, "Where is the Apache Camel for AI agents?"

Three months ago, there was maybe one serious Java agentic framework. Now, there are three—including Embabel. The race is on. But watching this explosion, I'm forced to ask a difficult question: Is the framework itself becoming an anti-pattern? Are we creating a liability for ourselves instead of focusing on what really matters—building agents?

The recent boom in Java agentic frameworks isn't a sign of a healthy, maturing ecosystem. It's a symptom. A code smell at the architectural level that tells us something is fundamentally wrong with our approach.

Why Did We Build Frameworks in the First Place?

Let's rewind. Why did frameworks like Spring and Camel become so dominant? The reasons were clear and valid:

Developer Productivity: We were drowning in boilerplate code. Frameworks abstracted it away.

Code Quality & Governance: They provided standardized patterns that prevented every developer from reinventing the wheel (often poorly).

Reusability: They gave us battle-tested constructs to build upon, saving immense time and effort.

The goal was to optimize for productivity, quality, and governance. But are those the same parameters we should be optimizing for today? It feels like we're trying to solve a 2010 problem in 2025, completely ignoring the elephant in the room: AI-powered developer tools.

The Elephant Has a Name: Cursor (and Friends)

Here's what changed while we were busy porting LangChain to Java:

Cursor and GitHub Copilot can generate boilerplate faster than you can type an import statement. That elaborate chain abstraction you're building? Cursor writes it in three seconds. That tool registration pattern you're standardizing? Copilot already knows five variations.

But here's where we need to stop and ask a more fundamental question: What does your end user actually need?

What Do You Really Need to Build?

Let's get specific. There are two scenarios most of us face:

Scenario 1: You're building one critical agent over the next 12 months. Maybe it's a customer service agent handling 10,000 conversations a day. Or a code review agent that needs to understand your company's specific standards. Or a compliance agent that must never hallucinate on regulatory requirements.

Scenario 2: You're building an agent platform. Hundreds or thousands of agents, each with different contexts, different domains, different requirements. Maybe you're at a consultancy building agents for multiple clients. Or you're creating an internal platform where different teams can spin up their own agents. You need something reusable, adaptable, evolvable. Something that lets you create new agents quickly while maintaining consistency and quality across all of them.

In both cases, ask yourself honestly: Does your user need a code framework?

Or do they need something completely different?

Redefining the Framework

Here's what I've learned after abandoning my framework and actually shipping agents: We don't need to eliminate frameworks. We need to redefine what a framework actually means in the AI era.

The old framework definition: A reusable code abstraction that provides structure and handles cross-cutting concerns. Something you import and build on top of.

The new framework definition: The complete environment for building agents—a set of interdependent layers that work together, where the code layer is just one piece of a larger puzzle.

Here are the layers that actually matter in a modern agent framework:

Layer 1: The Language Itself

Java (or your language of choice) with its constructs, types, and patterns. Not wrapped in abstractions—used directly. The language is already your framework for structuring logic. You don't need a code framework on top of Java. Java IS the framework.

Layer 2: The Model

A really good LLM—GPT-4, Claude, Gemini. This isn't just an API you call. It's a core component of your stack. The model's capabilities directly determine what you can build. Choose it as carefully as you'd choose your programming language.

Layer 3: Developer Productivity Tools

Cursor, Copilot, and the next generation of AI-powered dev tools. These are NOT optional. They're critical infrastructure. Your framework should be designed to work seamlessly with these tools. If Cursor can't easily generate code in your pattern, your pattern is wrong.

Layer 4: Prompt Packs & Guidelines

Your versioned, tested, governed prompts. Your organizational voice. Your domain knowledge. Your compliance rules. This is where your business logic lives—not in code, but in carefully curated context and instructions. Think of these as your dependency artifacts, like JARs, but for agent behavior.

Layer 5: Ecosystem APIs

Context awareness about the emerging ecosystem of specialized platforms and their APIs. Vector databases for knowledge retrieval. Context stores and memory management systems like Zep. Tool execution platforms like Arcade. Observability platforms for agent monitoring. Prompt management and versioning tools. Most of these expose REST APIs or standard protocols, most of these provide LLM.txt for context import. Your framework needs awareness that these exist and knowledge of how to connect to them.

Layer 6: Architecture & Design Patterns

Architectural thinking captured as guidelines and patterns. Reusable blueprints for how these layers compose together across different use cases. Not code abstractions—documented knowledge on routing logic, versioning strategies, deployment patterns, and ecosystem integration that becomes part of your organizational context.

Think about it. When you build that critical customer service agent, what actually determines its success?

The Java code that calls the LLM? (That's 20 lines, Cursor writes it)
The elaborate chain orchestration? (Standard control flow)
The retry logic and error handling? (Java already has patterns for this)

Or is it:

The model you chose and how well it handles your domain
The prompts that teach it your escalation rules and voice
The tooling that lets you iterate rapidly on those prompts
The integrations with platforms like Arcade for tools and Zep for memory
The architecture that lets you version, test, and deploy changes
The design patterns that let you reuse this approach across agents

That's your framework. All six layers, working together.

The Framework in Practice

Let me show you what this actually looks like when you're building agents:

Layer 4 (Prompt Packs) are versioned artifacts, not strings in your code:

prompts/
  customer-service/
    v1.2/
      system-prompt.md
      escalation-rules.md
      tone-guidelines.md
      product-context.md
      examples/
        refund-scenarios.yaml
        technical-issues.yaml

Layer 5 (Ecosystem APIs) configuration in your environment:

# .env
ARCADE_API_KEY=your_arcade_key
ARCADE_GATEWAY=https://api.arcade-ai.com
ZEP_API_URL=https://api.getzep.com/v2
ZEP_API_KEY=your_zep_key
VECTOR_DB_URL=https://your-vector-db.com

Your ecosystem context is embedded in guidelines:

# Ecosystem Integration Guidelines

## Tool Discovery
- Call Arcade API to list available tools: GET /tools
- Reference: See Arcade LLM.txt at https://docs.arcade.dev/llms.txt

## Memory Management
- Zep session API: https://api.getzep.com/v2/sessions/{session_id}
- Reference: See Zep API docs at https://docs.getzep.com

## Infra & Storage
- Object storage for prompt artifacts: S3, GCS, or Azure Blob
- Vector DB for knowledge retrieval: Pinecone, Weaviate, or Qdrant endpoints
- State persistence for long-running workflows

Layer 1 (Java) provides the structure, clean and simple:

public class CustomerServiceAgent {
    private final Model model;
    private final PromptPack prompts;
    private final ArcadeClient tools;
    private final ZepMemory memory;

    public Response handle(CustomerQuery query) {
        // Retrieve conversation memory
        var history = memory.getSession(query.sessionId());

        // Get available tools from Arcade
        var availableTools = tools.listTools();

        // Render prompt with context
        var context = prompts.render("main", query, history, availableTools);

        return model.complete(context);
    }
}

Layer 3 (Cursor) generates this code in seconds. You focus on the architecture.

Layer 6 (Architecture) guidelines:

# Agent Architecture Guidelines

## Workflow Routing
- Design routing logic for multi-node agent workflows
  - Classification node → routes to specialist nodes (support, sales, technical)
  - Complexity analysis → routes to appropriate model tier (GPT-4o vs GPT-3.5)
  - Tool selection node → routes to tool execution nodes based on user intent
- Implement state machines for complex workflows with conditional branches
- A/B routing for prompt versions: 10% to v2.0, 90% to v1.5, monitor quality...

## Rate Limiting & Throttling  
- Per-user token budgets: 10K tokens/day (free), 100K (paid)
- Route tool execution through Arcade gateway: centralized auth, rate limiting, tool discovery
- Queue management: Max 100 concurrent requests, overflow to SQS...

## Versioning & Deployment
- Semantic versioning for prompts (v1.2, v2.0)
- Decouple prompt deployments from code deployments
- Blue-green rollouts with instant rollback capability...

Why This Framework Scales

For one critical agent: Pick your model (Layer 2), write clean code (Layer 1), iterate with Cursor (Layer 3), refine prompts (Layer 4), integrate ecosystem APIs (Layer 5), follow architectural patterns (Layer 6).

For a thousand agents: Same model, same architectural patterns, same ecosystem APIs—but each agent gets its own prompt pack. Cursor generates the boilerplate. Your language provides structure. The ecosystem handles the hard problems.

The beauty? The layers work together. Cursor generates code because patterns are simple. Prompts are independently versioned. Integrations use REST APIs. Architecture enables reuse without abstraction.

No orchestration framework needed. This IS the framework.

The Engine vs. SDK Question

Let me be clear: I'm not saying all frameworks should disappear. I have tremendous respect for what the teams at LangChain, LangGraph, Maastra, and others have built. But we need to understand a critical distinction that's getting lost in the rush to port everything to Java.

Don't confuse an engine with an SDK.

Here's what I mean: I can't wait to develop full agents in Java. I love Java. But I don't want a Java engine just because I want to develop agents in Java.

Consider these examples:

LangChain4J? Great start as an SDK that connects to the broader LangChain ecosystem. You write in Java, but you're leveraging a proven engine.

Crew AI with a Java SDK? Perfect. Master the orchestration patterns in Python, then give me a Java interface to use them.

Maastra with multi-language support? Exactly the right direction. Build the engine once, provide SDKs for every language.

The pattern here? Develop in your preferred language without rebuilding the entire engine in that language.

We're building Java engines for agent orchestration when we should be building Java SDKs to proven engines. And honestly? Even that might be overkill.

The Orchestration Layer is Getting Thinner

Here's why I think even the SDK approach might be temporary, or at least becoming far more minimal:

On one side: Models are getting dramatically better. GPT-4, Claude 3.5, and Gemini have reasoning capabilities that make complex orchestration patterns obsolete. They can handle multi-step workflows with simple prompts that would have required elaborate chains six months ago.

On the other side: The real engineering problems are being solved by specialized platforms. Take Arcade as an example—tool discovery, authentication, execution at scale, handling rate limits, managing tool versions. That's where the hard engineering work is. Tool management isn't an orchestration problem anymore; it's an infrastructure problem being solved at the platform layer.

In the middle: Orchestration frameworks are being squeezed thinner and thinner.

When your model can reason through workflows and platforms handle the complex engineering problems (tools, memory, context), what's left for orchestration?

The answer: Very little. And that's why the engineering focus needs to shift from orchestration to the broader agent development challenges—prompt management, ecosystem integration, decision auditability, cost optimization. The real problems aren't in orchestration anymore.

The New Reality: AI-Native Frameworks

The code smell isn't just that we're building too many frameworks. It's that we're building frameworks for a world that no longer exists. Here's what building frameworks in 2025 actually means:

1. Accept the AI-powered development reality

Every developer building agents will use Cursor, Copilot, or similar tools. That's not a trend—it's the new baseline. Design your framework to work seamlessly with AI code generation, not against it. If Cursor can't understand your patterns, your patterns are wrong.

2. Your framework is plain English, not just code

The most critical parts of your framework will be well-engineered prompts, clear guidelines, and structured context—not clever abstractions. These are your versioned artifacts. These determine agent behavior. Treat them with the same rigor you treat code.

3. Don't reinvent engines when you need SDKs

Yes, Java SDKs are critical. But you don't need to rebuild entire orchestration engines just to write agents in Java. The ecosystem already has platforms solving the hard problems: memory (Zep, Mem0, LangMem), tools (specialized platforms), vectors (Pinecone, Weaviate, Qdrant), observability (LangSmith, Helicone, Langfuse). Integrate, don't rebuild.

4. Frameworks are still critical—but not for orchestration

If you're solving real problems—prompt versioning, decision auditability, ecosystem integration patterns, cost optimization—build that. But orchestration? The ecosystem has moved on. Memory, tools, context, observability are being solved by specialized platforms. Focus your innovation elsewhere.

5. Trust your language

If you feel there's a framework missing in your language of choice, step back. Modern languages—Java, Python, TypeScript, Go—are incredibly powerful. With their latest features plus AI code generation tools, you can build sophisticated agents with clean, simple code. Your language isn't the limitation—trying to wrap it in unnecessary abstractions is.

The framework of the future isn't a code library you import. It's mastery of six interdependent layers: your language, your model, your dev tools, your prompts, your ecosystem integrations, and your architecture.

Maybe we don't need another agentic framework. Maybe all we need is an agent—one that creates agents in the language of your choice. An open-source one would be even better.

Stop building orchestration frameworks. Start building agents.