How Elixir Helped Us Integrate AI Agents at Lightning Speed

Integrating AI agents into a live product often sounds like a long, expensive journey—one filled with new dependencies, external services, and unpredictable costs. But with the right stack, it doesn’t have to be.

In our latest project, we achieved lightning-fast Elixir AI integration by combining LangChain and Reactor to orchestrate AI agents seamlessly within our existing infrastructure. The result? A full production-grade system built in weeks, not months—without adding external services, new runtimes, or enterprise license costs.

When our team decided to enhance a product with AI-driven agents, we faced two main constraints:

1. Speed. We wanted results in weeks, not months.

2. Efficiency. We couldn’t afford a spike in infrastructure or license costs.

The market offers plenty of automation tools—n8n, Airflow, Temporal, and others—that promise fast integration through visual flows and connectors. But for enterprise deployments, the total cost can rise quickly. Hosting, scaling, and maintaining these tools introduces complexity that doesn’t always justify the convenience.

So we looked inward. What if we could achieve the same capabilities using our existing Elixir-based architecture?

We were lucky. Elixir was already a key part of our technology stack, powering several of our production systems. Its actor-based concurrency model, fault tolerance, and supervision trees had proven ideal for handling high-volume, asynchronous workflows.

That familiarity meant we had everything we needed at home to experiment—and, if it worked, to move straight into production.

Instead of introducing a new runtime or external orchestration engine, we decided to extend our Elixir ecosystem to support AI agent workflows directly. That’s when two main building blocks came into play: Model Context Protocol (MCP) tools and the LangChain + Reactor combination.

Before we could run any agent, we needed a consistent way for AI components to communicate with the rest of the system. That’s where Model Context Protocols (MCPs) came in.

And here’s where our tech stack gave us a major advantage. Since we use Ash Framework with Elixir, building the MCP layer was almost trivial. Ash’s declarative design and resource-based architecture made it easy to expose data and actions to AI agents in a consistent, structured way. What would typically require custom endpoints or glue code in other stacks became a few lines of configuration in ours.

In fact, in the final part of this post, we’ll share a simple example of how this was done—to demonstrate just how accessible and flexible the approach can be.

This foundation was crucial. Once the MCP tools were in place, integrating and orchestrating AI behavior became the easy part.

With the MCP layer working, we needed a runtime capable of managing multiple AI agents—each with its own tools, reasoning steps, and communication flow. After evaluating various frameworks, we found that LangChain fit perfectly.

LangChain provided the structure we needed to compose complex agent behaviors, chain reasoning steps, and manage prompt templates—all within a clear, modular framework. Each “chain” represented a sequence of thought and action, and combining it with Elixir’s Reactor library allowed us to run these chains reactively and concurrently inside our infrastructure.

Here’s why this pairing worked so well:

• Smooth orchestration. LangChain handled logic composition and memory, while Reactor managed concurrency and resilience.

• No new infrastructure. Everything ran within the same Elixir cluster already powering our services.

• Unified observability. Monitoring and debugging were native to our system since the entire flow stayed in the same stack.

Within weeks, we had multiple agents running in production—processing data, generating insights, and coordinating with other services in real time.

The best part? The total runtime cost was essentially zero additional dollars. We were using the same compute resources already in place.

It’s worth pausing to compare this outcome with what it would have looked like using a commercial automation platform like n8n Enterprise.

Even before considering performance, the financial contrast is striking. In our case, running n8n in enterprise mode can easily exceed $24,000 per year, since we need over 150k execution per workflow, not including infrastructure or DevOps time.

In our case, the LangChain + Reactor stack ran on the same infrastructure already supporting the application. The effective incremental cost was negligible.

That translated to both cost savings and operational independence—no license renewals, no scaling limits, no vendor lock-in.

After deploying our first generation of AI agents, several lessons stood out:

1. Architecture matters more than tooling. Elixir’s concurrent model gave us everything we needed to orchestrate complex agent interactions—without reinventing the wheel or paying for external schedulers.

2. Simplicity scales better than complexity. Because the MCP layer was built internally, we understood every piece of the integration. Troubleshooting and extending it became straightforward, and performance remained predictable.

3. LangChain is powerful—but Elixir makes it practical. LangChain provided the mental model for reasoning and chaining logic, while Reactor ensured fault tolerance and concurrency. Together, they turned a theoretical framework into a production-ready engine.

4. Ownership pays off. Building internally required an initial investment of effort, but it paid dividends in flexibility and cost savings. We can now adapt our agent runtime freely as AI frameworks evolve.

Integrating AI agents doesn’t have to mean overhauling your stack or signing up for new enterprise licenses. In our experience, the best results came from leveraging what we already knew and trusted: Elixir.

By building our own MCP tools and using LangChain + Reactor for orchestration, we turned a potentially complex, high-cost project into a fast, efficient, and internally owned success story.

For other teams exploring AI integration, the key takeaway is clear:

Sometimes the fastest path forward isn’t adding something new—it’s realizing the power of what you already have.

In this post, we focused on the architectural journey—how Elixir, Ash Framework, and LangChain came together to make agent integration fast and efficient.

But we know that seeing is believing. In the next section, we’ll share a concise example of how our MCP implementation was built using Ash, to show just how simple it can be to connect your own data and tools to AI agents inside an Elixir ecosystem.

Diagram of how an LLM (MCP Client) can interact with our API through an MCP Server. The MCP Server acts as an additional layer on top of your existing API, exposing selected resources as tools that the AI can invoke.

We used the AshAi library, which provides a pre-built MCP server. You can mount it directly in your Phoenix router under a chosen path (e.g. /mcp) by forwarding requests to AshAi.Mcp.Router, along with the set of tools you want to expose. The workflow is the following:

1. Requests to /mcp/* pass through the :mcp pipeline, which enforces API key authentication.

2. A plug validates the API key and resolves it to a valid actor (user). That actor becomes the execution context for any tool calls.

3. AshAi.Mcp.Router then processes the MCP protocol messages (e.g. “call tool X with these args”).

Code snippet configuring an MCP server in the application’s router file.

In MCP, the application’s tools are simply the actions you choose to expose to the LLM. In our case, we started with the :read_users tool, which maps to the existing read action already defined on the User resource inside the Accounts domain.

Code snippet of a tool definition for an application resource.

This means the AI model can now answer prompts such as:

• “Show me info of the user with email [email protected]”
• “List the user IDs of accounts created in the last month.”

Behind the scenes, the LLM translates these natural-language prompts into structured MCP requests, which run through the same API and policies already defined in the system.

Because the tools are backed by Ash actions and subject to existing policies and validations, the LLM can never bypass your business logic.

Beyond reads, the same setup can safely enable the model to create, update, or delete resources — but only when the policies explicitly allow it.

This makes MCP a powerful and secure way to let AI interact with your application without losing control.

Ash provides a powerful and convenient command-line interface (CLI) tool that automates the initial setup, allowing you to integrate an MCP server into your existing application with minimal effort:

When you execute this command in your application’s root directory, Ash performs the necessary modifications to your router. Specifically, it will:

Integrate an MCP Server: Ash injects the essential code to instantiate and run an MCP server directly within your application’s router. This means your application will be ready to accept and process requests from MCP clients.

Establish a Tooling Interface: The command also sets up the foundational structure for defining and managing the tools that your MCP server will expose. Tools are essentially representations of the actions or functionalities within your application that you want to make accessible to external clients through the MCP.

Once we’ve generated our MCP server, the primary remaining task is to define the specific actions your MCP server will offer and then register them. This involves a few key steps:

1. Identify exposable actions: Begin by reviewing your application’s resources and identifying the actions (e.g., create_user, get_product_details, update_order_status) that you wish to make available via the MCP. Each of these actions will correspond to a distinct tool.

2. Create tools in your resource’s domain: For each identified action, create a corresponding tool. These tools are typically defined within the domain of the resource they operate on. This ensures logical organization and makes it clear which tools relate to which parts of your application.

3. Register tools in your router: After creating your tools, the final step is to inform your MCP server about their existence. This is done by adding the names of your newly created tools to a designated tools array within your application’s router configuration. When an MCP client sends a request, the MCP server consults this array to determine if it has a corresponding tool to handle the request.

In essence, the process boils down to:

1. Run mix ash_ai.gen_mcp: Automate the initial MCP server setup.

2. Identify actions: Determine which resource actions you want to expose.

3. Create tools: Define the MCP-compatible representations of these actions within your resource domains.

4. Register tools: Add the tool names to your router’s tools array.

By following these steps, you can quickly and efficiently get an MCP server up and running, opening up new possibilities for integrating your application with a wide range of external clients and services.

If you’re exploring how to integrate AI agents without increasing infrastructure complexity or vendor costs, you’re not alone. At Folder IT, we help teams integrate AI without added complexity.
From app modernization to AI-powered solutions, our experts can help you move faster, scale smarter, and stay in control. Contact us to start your next project.