Fintech Brex is betting that the future of enterprise AI isn’t better orchestration — it’s less of it.
As generative AI agents move from copilots to autonomous systems, Brex CTO James Reggio says traditional agent orchestration frameworks are becoming a constraint rather than an enabler. Instead of relying on a central coordinator or rigid workflows, Brex has built what it calls an “Agent Mesh”: a network of narrow, role-specific agents that communicate in plain language and operate independently — but with full visibility.
“Our goal is to use AI to make Brex effectively disappear,” Reggio told VentureBeat. “We’re aiming for total automation.”
Brex learned that for its purposes, agents need to work in narrow, specific roles to be more modular, flexible, and auditable.
Reggio said the architectural goal is to enable every manager in an enterprise “to have a single point of contact within Brex that’s handling the totality of their responsibilities, be it spend management, requesting travel, or approving spend limit requests.”
The financial services industry has long embraced AI and machine learning to handle the massive amounts of data it processes. But when it comes to bringing AI models and agents, the industry took a more cautious road at the beginning. Now, more financial services companies, including Brex, have launched AI-powered platforms and several agentic workflows.
Brex’s first foray into generative AI was with its Brex Assistant, released in 2023, which helped customers automate certain finance and expense tasks. It provides suggestions to complete expenses, automatically fills in information, and follows up on expenses that violate policies.
Reggio acknowledges that Brex Assistant works, but it’s not enough. “I think to some degree, it remains a bit of a technology where we don’t entirely know the limits of it,” he said. “There’s quite a large number of patterns that need to exist around it that are kind of being developed by the industry as the technology matures and as more companies build with it.”
Brex Assistant uses multiple models, including Anthropic’s Claude and custom Brex-models, as well as OpenAI’s API. The assistant automates some tasks but is still limited in how low-touch it can be.
Reggio said Brex Assistant still plays a big role in the company’s autonomy journey, mainly because its Agent Mesh product flows into the application.
The consensus in the industry is that multi-agent ecosystems, in which agents communicate to accomplish tasks, require an orchestration framework to guide them.
Reggio, on the other hand, has a different take. “Deterministic orchestration infrastructure … was a solution for the problems that we saw two years ago, which was that agents, just like the models, hallucinate a lot,” Reggio said. “They’re not very good with multiple tools, so you need to give them these degrees of freedom, but in a more structured, rigid system. But as the models get better, I think it’s starting to hold back the range of possibilities that are expanding.”
More traditional agent orchestration architectures either focus on a single agent that does everything or, more commonly, coordinator/orchestrator plus tool agents that explicitly define workflows. Reggio said both frameworks are too rigid and solve issues more commonly seen in traditional software than in AI.
The difference, Reggio argues, is structural:
Traditional orchestration: predefined workflows, central coordinator, deterministic paths
Agent Mesh: event-driven, role-specialized agents, message-based coordination
Agent Mesh relies on stitching together networks of many small agents, each specializing in a single task. The agents, once again using the hybrid mix of models as with the Brex Assistant, communicate with other agents “in plain English” over a shared message stream. A routing model quickly determines which tools to invoke, he said.
A single reimbursement request triggers several tasks: a compliance check to align with expense policies, budget validation, receipt matching, and then payment initiation. While an agent can certainly be coded to do all of that, this method is “brittle and error-prone,” and it responds to new information shared through a message stream anyway.
Reggio said the idea is to disambiguate all of those separate tasks and assign them to smaller agents instead. He likened the architecture to a Wi-Fi mesh, where no single node controls the system — reliability emerges from many small, overlapping contributors.
“We basically found a really good fit with the idea of embodying specific roles as agents on top of the best platform to manage specific responsibilities, much like how you might delegate accounts payable to one team versus expense management to another team,” Reggio said.
Brex defines three core ideas in the Agent Mesh architecture:
Config, where definitions of the agent, model, tools and subscription live
MessageStream, a log of every message, tool call and state transition
Clock, which ensures deterministic ordering
Brex also built evaluations into the system, in which the LLM acts as a judge, and an audit agent reviews each agent’s decisions to ensure they adhere to accuracy and behavioral policies.
Brex says it has seen substantial efficiency gains among its customers in its AI ecosystem. Brex did not provide third-party benchmarks or customer-specific data to validate those gains.
But Reggio said enterprise customers using Brex Assistant and the company’s machine learning systems “are able to achieve 99% automation, especially for customers that really leaned into AI.”
This is a marked improvement from the 60 to 70% Brex customers who were able to automate their expense processes before the launch of Brex Assistant.
The company is still early in its autonomy journey, Reggio said. But if the Agent Mesh approach works, the most successful outcome may be invisible: employees no longer thinking about expenses at all.
For decades, we have adapted to software. We learned shell commands, memorized HTTP method names and wired together SDKs. Each interface assumed we would speak its language. In the 1980s, we typed ‘grep’, ‘ssh’ and ‘ls’ into a shell; by the mid-2000s, we were invoking REST endpoints like GET /users; by the 2010s, we imported SDKs (client.orders.list()) so we didn’t have to think about HTTP. But underlying each of those steps was the same premise: Expose capabilities in a structured form so others can invoke them.
But now we are entering the next interface paradigm. Modern LLMs are challenging the notion that a user must choose a function or remember a method signature. Instead of “Which API do I call?” the question becomes: “What outcome am I trying to achieve?” In other words, the interface is shifting from code → to language. In this shift, Model Context Protocol (MCP) emerges as the abstraction that allows models to interpret human intent, discover capabilities and execute workflows, effectively exposing software functions not as programmers know them, but as natural-language requests.
MCP is not a hype-term; multiple independent studies identify the architectural shift required for “LLM-consumable” tool invocation. One blog by Akamai engineers describes the transition from traditional APIs to “language-driven integrations” for LLMs. Another academic paper on “AI agentic workflows and enterprise APIs” talks about how enterprise API architecture must evolve to support goal-oriented agents rather than human-driven calls. In short: We are no longer merely designing APIs for code; we are designing capabilities for intent.
Why does this matter for enterprises? Because enterprises are drowning in internal systems, integration sprawl and user training costs. Workers struggle not because they don’t have tools, but because they have too many tools, each with its own interface. When natural language becomes the primary interface, the barrier of “which function do I call?” disappears. One recent business blog observed that natural‐language interfaces (NLIs) are enabling self-serve data access for marketers who previously had to wait for analysts to write SQL. When the user just states intent (like “fetch last quarter revenue for region X and flag anomalies”), the system underneath can translate that into calls, orchestration, context memory and deliver results.
To understand how this evolution works, consider the interface ladder:
|
Era |
Interface |
Who it was built for |
|
CLI |
Shell commands |
Expert users typing text |
|
API |
Web or RPC endpoints |
Developers integrating systems |
|
SDK |
Library functions |
Programmers using abstractions |
|
Natural language (MCP) |
Intent-based requests |
Human + AI agents stating what they want |
Through each step, humans had to “learn the machine’s language.” With MCP, the machine absorbs the human’s language and works out the rest. That’s not just UX improvement, it’s an architectural shift.
Under MCP, functions of code are still there: data access, business logic and orchestration. But they’re discovered rather than invoked manually. For example, rather than calling “billingApi.fetchInvoices(customerId=…),” you say “Show all invoices for Acme Corp since January and highlight any late payments.” The model resolves the entities, calls the right systems, filters and returns structured insight. The developer’s work shifts from wiring endpoints to defining capability surfaces and guardrails.
This shift transforms developer experience and enterprise integration. Teams often struggle to onboard new tools because they require mapping schemas, writing glue code and training users. With a natural-language front, onboarding involves defining business entity names, declaring capabilities and exposing them via the protocol. The human (or AI agent) no longer needs to know parameter names or call order. Studies show that using LLMs as interfaces to APIs can reduce the time and resources required to develop chatbots or tool-invoked workflows.
The change also brings productivity benefits. Enterprises that adopt LLM-driven interfaces can turn data access latency (hours/days) into conversation latency (seconds). For instance, if an analyst previously had to export CSVs, run transforms and deploy slides, a language interface allows “Summarize the top five risk factors for churn over the last quarter” and generate narrative + visuals in one go. The human then reviews, adjusts and acts — shifting from data plumber to decision maker. That matters: According to a survey by McKinsey & Company, 63% of organizations using gen AI are already creating text outputs, and more than one-third are generating images or code. (While many are still in the early days of capturing enterprise-wide ROI, the signal is clear: Language as interface unlocks new value.
In architectural terms, this means software design must evolve. MCP demands systems that publish capability metadata, support semantic routing, maintain context memory and enforce guardrails. An API design no longer needs to ask “What function will the user call?”, but rather “What intent might the user express?” A recently published framework for improving enterprise APIs for LLMs shows how APIs can be enriched with natural-language-friendly metadata so that agents can select tools dynamically. The implication: Software becomes modular around intent surfaces rather than function surfaces.
Language-first systems also bring risks and requirements. Natural language is ambiguous by nature, so enterprises must implement authentication, logging, provenance and access control, just as they did for APIs. Without these guardrails, an agent might call the wrong system, expose data or misinterpret intent. One post on “prompt collapse” calls out the danger: As natural-language UI becomes dominant, software may turn into “a capability accessed through conversation” and the company into “an API with a natural-language frontend”. That transformation is powerful, but only safe if systems are designed for introspection, audit and governance.
The shift also has cultural and organizational ramifications. For decades, enterprises hired integration engineers to design APIs and middleware. With MCP-driven models, companies will increasingly hire ontology engineers, capability architects and agent enablement specialists. These roles focus on defining the semantics of business operations, mapping business entities to system capabilities and curating context memory. Because the interface is now human-centric, skills such as domain knowledge, prompt framing, oversight and evaluation become central.
What should enterprise leaders do today? First, think of natural language as the interface layer, not as a fancy add-on. Map your business workflows that can safely be invoked via language. Then catalogue the underlying capabilities you already have: data services, analytics and APIs. Then ask: “Are these discoverable? Can they be called via intent?” Finally, pilot an MCP-style layer: Build a small domain (customer support triage) where a user or agent can express outcomes in language, and let systems do the orchestration. Then iterate and scale.
Natural language is not just the new front-end. It is becoming the default interface layer for software, replacing CLI, then APIs, then SDKs. MCP is the abstraction that makes this possible. Benefits include faster integration, modular systems, higher productivity and new roles. For those organizations still tethered to calling endpoints manually, the shift will feel like learning a new platform all over again. The question is no longer “which function do I call?” but “what do I want to do?”
Dhyey Mavani is accelerating gen AI and computational mathematics.