Inside Brex’s AI Engineering: Platforms, Specialists, and Agent Networks

A startup inside an existing business

Brex’s recruiting pitch addresses a practical problem for would-be financial AI founders: reaching customers. In the Latent Space conversation, CTO James Reggio describes offering engineers interesting financial problems with potential distribution to roughly 40,000 customers, spanning startups and Fortune 100 companies. The accompanying challenge is organizational: give those engineers enough independence to build as they would in a startup.

Reggio was considering leaving to start another company when Brex offered him the CTO role. He credits his founder experience more than his front-end engineering background for preparing him: the job requires business judgment and leadership alongside technical depth. Brex’s Quitters Welcome recruiting proposition extends that outlook to employees, celebrating those who leave to become founders or department heads and offering experience at a scale their own companies may not have reached.

At the time of the conversation, Brex had about 300 engineers, largely organized around cards, bank accounts, expenses, travel, and accounting. Each domain covered infrastructure through web and mobile experiences. A separate AI team of roughly ten people was formed around a question: what would a company founded today to disrupt Brex look like?

Small pods combine a product- or customer-focused person, a staff engineer familiar with Brex’s code and business, and a younger engineer skilled at working with agents. Hiring follows a pre-seed startup philosophy: protect talent density and add people deliberately. Friday demos provide executive feedback. The team concentrates on the newer agent layer; smaller applications of large language models, or LLMs, remain distributed across product and operations teams.

Brex’s emphasis on business impact reportedly reduced resentment over access to AI work. Established products offered clearer revenue impact, while interested engineers could transfer—one brought expense-policy expertise into the AI team. The business results mentioned early in the interview need a separate qualification: Alessio reads a statement attributed to Pedro claiming fivefold growth acceleration and a 99% reduction in burn over 18 months. Those figures lack metric definitions and a breakdown of AI’s contribution, so they cannot serve as an AI productivity measurement.

Shared infrastructure, different frameworks

Brex built its initial LLM platform around January 2023, according to the recollection in the interview. It handled prompt deployment, management, versioning, and evaluation. An LLM gateway controlled data leaving the system and routed requests to models, with basic observability and cost monitoring. The platform continued to power narrower applications, including research agents that evaluate customer applications and perform work previously requiring human underwriting or customer checks.

The newer agent layer used TypeScript, with Mastra as a primary framework, alongside pgvector and Pinecone. It connected through public interfaces to remain at arm’s length from Brex’s Kotlin and Elixir product core. Mastra’s ergonomics resembled the original internal framework and supplied the features the team needed, reducing the appeal of maintaining equivalent infrastructure itself.

Framework choices remained provisional. Brex’s earlier rejection of LangChain concerned observability, logging, and tracing at that time; the conversation acknowledges that those gaps were subsequently addressed. Roughly half the agent-layer applications under development used Mastra, while the rest used another internal framework for networks of agents. The team considered strict workflows and single-turn applications easier fits for Mastra or LangGraph. Its network architecture was evolving fast enough that a planned technical post was partly outdated before publication.

Specialists that can ask questions

Brex serves two broad audiences. Finance professionals need agents suited to their roles; employees using their employer’s account mostly want administrative work to disappear. The employee-facing ambition is an executive assistant with calendar, email, and travel context that can handle booking and expense documentation. Ideally, the interface becomes SMS and the card.

One agent with many tools and additional context struggled to cover all of Brex’s product lines. Dynamically adding reimbursement context to its prompt also reportedly worked less well than consulting a dedicated reimbursement agent, though the comparison was qualitative. Brex therefore introduced an orchestrator, the employee-facing coordinator, backed by specialists for expenses, reimbursements, travel, policy, and procurement. Specialists attach according to the products a company uses.

This applies software encapsulation to agent behavior. A domain team can improve its specialist with less risk of affecting unrelated behavior, without one central team owning every employee action. Brex’s custom framework supports agents exchanging messages over multiple turns and was built partly to make those interactions easier to evaluate.

A dinner-expense question shows why multiple turns matter: 1. An employee asks how much they may expense per person. 2. The assistant consults the policy agent. 3. The policy agent needs to distinguish a customer event, a team event, or travel-related dining. 4. It asks the assistant to obtain clarification from the employee before answering. The specialist knows both the policy and which missing facts determine the answer.

These conversations are distinct from individual tool calls into conventional software systems. Specialists still use many tools, but coordinating a task may require an exchange rather than one request and response. An earlier implementation represented each subagent as a tool with natural-language input and output, repeatedly passing the full conversation history to support multiple turns. That awkward interface motivated an explicit messaging model: an assistant holding short conversations with specialists.

Three kinds of AI investment

Brex’s broader strategy grew from a coordination problem: scattered LLM features and operational experiments were difficult to turn into an investment roadmap. Grouping projects, ambitions, and business problems produced three categories: - Corporate AI: buy and adopt tools for employee workflows, with tenfold improvement as an ambition. - Operational AI: buy and build automation to lower financial-institution operating costs, including fraud detection, underwriting, customer checks, and card disputes. - Product AI: build capabilities customers can adopt as part of their own corporate AI strategies.

IT and the people team drove much of corporate adoption through procurement and employee experimentation. Operational AI had a different constraint: automate work across an organization employing hundreds of people while preserving service quality and helping employees change roles. Engineering invested in ways for fraud and risk specialists to refine prompts and evaluations, shifting their work from executing standard operating procedures to improving the systems that execute them.

Shared infrastructure connected these categories without requiring a universal stack: operational and product agents reused tools. One operational target was 80% automated acceptance for startup and commercial applicants, with fully touchless decisions within 60 seconds. The platform enabled rapid development toward that target; achievement of the target was not reported.

After adoption comes code ownership

Brex buys small numbers of seats across competing AI products and lets employees choose. Through Conductor One in Slack, employees can obtain ChatGPT, Claude, or Gemini licenses; developers can choose Cursor, Windsurf, or Claude Code credits. Enterprise agreements provide privacy and non-training guarantees. Adoption dashboards inform budgets and help Brex resist company-wide commitments at renewal.

Once engineers became comfortable with agentic coding, the challenge shifted from encouraging first use to encouraging experimentation with alternatives. Familiar workflows could outweigh a new model’s appeal. Brex collects commit co-author statistics, but does not use them to guide its judgment of adoption: the interview rejects the idea that it has an honest calculation of the percentage of code written by AI.

More consequential signals appear downstream: low-quality generated code, insufficient review, and drift in teammates’ understanding of their services. As engineers change code faster and more independently, incident responders may find that a once-familiar service has become unfamiliar in a few months. An interviewer argues that AI review alone cannot resolve this ownership problem: people still need to understand, debug, and operate the growing codebase.

The discussion also questions simple assumptions about junior engineers. At one dinner, college juniors and seniors described using agents to develop architecture and implementation plans while writing much of the code themselves. Another participant raises the concern that inexperienced engineers may lack the context needed to guide those plans—for example, database-index choices depend on actual query patterns. A proposed role for senior engineers is to supply that knowledge to AI systems, while agent-assisted work increasingly involves task decomposition, supervision, and feedback.

Brex’s coding controls combine explicit Markdown rules, traditional linters, and Greptile for review beyond linting. Greptile receives praise for useful comments, rather than a measured accuracy claim. Early in the separate TypeScript repository, Claude Code in a GitHub Action also checked conceptual conventions that a rigid linter could not express, then posted an assessment of conformance to repository idioms. That experiment had worked well, but its continued use was uncertain as the team iterated.

Operational automation starts with the procedure

Brex initially invested in reinforcement learning for underwriting and credit-limit decisions, working with an outside specialist company. The reported performance was worse than that of a web research agent. This was a result from one attempt, without a disclosed metric, dataset, or evaluation procedure; it does not establish a general ranking of the approaches.

The practical lesson was that standard operating procedures, or SOPs, already divide work into repeatable, auditable steps. Many operational tasks needed relatively simple agents, sometimes only a single prompt and response. The difficult work was making prompts capture both the documented procedure and the unwritten institutional knowledge employees used to make decisions.

Brex prioritized tasks by frequency and breadth of customer impact. Researching a prospective business’s legitimacy and eligibility sits directly on the onboarding path. Card disputes offered a costly but less frequent target: the issuer turns customer evidence into a three- or four-page Word document for the card network and eventually the acquiring bank. Despite substantial overhead, that workflow came later because fewer customers encounter it.

The original business motivation was expansion into commercial customers such as law firms and dental offices. Human onboarding and servicing costs had made some slower-growing businesses uneconomic to serve. Brex still described its offering as suited to companies with some scale, typically at least one finance employee. The low end of its target profile was roughly $1 million in annual revenue or $10,000 in monthly card transactions.

That qualification reflects an earlier failure. Brex’s previous small-business expansion pursued volume with weaker controls and less underwriting experience. Tens of thousands of unprofitable customers became a severe burden. The newer effort aimed to make a broader customer base viable while taking a more deliberate approach to whom Brex should serve.

Give domain experts control of prompts and knowledge

Most operational AI continued to run on the original platform, with much of its interface built in Retool. Prompt, tool, and evaluation managers let operations staff refine behavior without engineers. When a new foundation model arrives, staff can run existing evaluations against it to compare performance, latency, and cost. The task-specific tests make model changes assessable by the people who understand the work.

Those agents also need a current description of the business. Models’ built-in knowledge could describe Brex as a card only for startups or a service only for enterprises. Brex curates product and process documentation to ground answers in current business information, reducing invented features and incorrect customer-eligibility decisions.

A unified knowledge source remained an aspiration: internal operations documents, customer documentation, sales materials, and frontline-support content were fragmented. For support itself, Brex bought Sierra, judging the problem insufficiently differentiated to justify building the surrounding management software. Operations and customer-experience teams could administer low-code workflows, engineers supplied action tools, and leadership received reporting and telemetry.

Evaluate decisions and conversations differently

Operational evaluations begin with an engineer and an operations expert co-developing an agent and its initial test set. Tests attach to individual prompts or agents. Operations quality assurance then reviews both human and LLM decisions; a discovered mistake almost always becomes another regression test. The evaluation set grows from failures in the actual workflow.

Product evaluations must assess success across a conversation. Brex gives a simulated-user agent an objective, lets it interact with the assistant over multiple turns, and uses an LLM judge—a model assessing the completed interaction—to evaluate the outcome. These runs resemble integration tests: they can exercise more of the system than intended. Prepared preambles or several handwritten turns let the team start closer to the behavior it wants to isolate.

Periodic human review also checks whether users appeared to accomplish their objectives. Brex distinguishes blocking accuracy regressions from subjective measures such as tone and coherence, which it tracks over time. Moving from incubation to a shipped assistant made regression prevention central, although product evaluation remained a work in progress.

The conversation introduces another possible use for evaluations: turn unsupported user requests into deliberately failing tests that might pass weeks or months later. Such tests could make capability growth visible. This was a proposal to explore, separate from the established regression checks.

One recurring failure makes the capability boundary concrete. The assistant sometimes offers to contact a finance team even though no corresponding tool exists and no action occurs. Its habit of consulting other agents appears to encourage invented delegation. The team reports addressing this through the system prompt rather than a regex. It used relatively few targeted guardrails; gateway support for last-chance circuit breakers existed, but was not believed to be active.

Learning by doing, including managers

Operations was ahead of engineering in formal AI learning pathways, partly because training at scale was already central to its work. Leadership paired the expectation that responsibilities would be automated with a message that employees’ jobs could change rather than necessarily disappear. Spot bonuses and an AI spotlight at biweekly all-hands rewarded useful experiments, often from operations, finance, and the people organization.

An interviewer names four fluency levels—user, advocate, builder, and native—but their assessment criteria are not explained. The discussion also does not exclude AI adoption from performance evaluation. Its stated distinction is that adoption should not become a rote measure of whether someone uses AI enough.

Engineering’s concrete intervention was a redesigned interview. Candidates receive a project brief beforehand and additional specifications at the start. Agentic coding is expected; interviewers observe the workflow and probe whether candidates understand the generated code. Brex then put every existing engineer, including managers, through the exercise. The internal run kept no scores or pass/fail records. Its purpose was to make opportunities for skill development tangible.

Faster code is not a staffing formula

Agentic development amplifies good engineering, but also misunderstood requirements, poor architecture, and sloppiness. Combining those effects makes the capacity gain less obvious than faster code production suggests. Brex’s stated headcount planning therefore did not assume that AI automatically meant fewer engineers; questions about staffing and junior-versus-senior hiring remained open.

Brex reports keeping engineering headcount flat during the CTO’s tenure while serving more customers and business lines, crediting improvements in execution, roadmapping, and project selection. Keeping roughly 300 engineers while becoming substantially more efficient over the following year was an aspiration, not a measured AI result.

The audit network: detect, review, then ask

The closing request is for people working on multi-agent networks to get in touch and help translate research into broadly usable tooling. The motivation is that deterministic workflows may constrain agents’ capacity for fluid planning and coordination. Brex’s own architecture remains mostly hierarchical: an employee’s assistant and specialists resemble a tree. Connections between finance-team agents and different employees’ assistants make the broader system more graph-like.

The launched audit agent illustrates that broader network. It ingests a customer’s SOPs and examines patterns across expenses that isolated checks might miss: repeated $74 transactions when receipts become mandatory at $75, DoorDash charges during business hours on days with an office-provided lunch, or rideshare patterns needing additional context. These are signals to investigate, not proof of misconduct.

The work proceeds in three stages: 1. Detection: the audit agent raises many potential violations to minimize missed problems. 2. Review: a separate agent decides which findings deserve a case, considering significance, dollar amount, and the employee’s broader compliance behavior. 3. Follow-up: filing a case triggers an event to the employee’s assistant, which collects business justification or draws on relevant conversation history. Broad detection and selective follow-up have distinct responsibilities. The employee’s assistant may already possess the context that explains an apparently unusual expense.

Brex had tried a similar concept with GPT-3.5 and encountered hallucinated tool calls. The closing assessment is that the technology had become robust enough to begin realizing that earlier vision—not a quantified reliability claim, but a practical shift from an unsuccessful experiment to agents coordinating real financial workflows.