Every few years, the software industry collectively discovers something it already knew and treats it like a revelation. Right now, that something is MCP.

The Model Context Protocol has been called “USB-C for AI.” It has been called a paradigm shift. Every vendor I talk to is racing to ship an MCP server. Every pitch deck has an MCP slide. The discourse is loud. And most of it misses the point entirely.

MCP is a way for a program to discover and invoke capabilities on a remote system using a structured, self-describing interface. That is also what an API is. That is also what a CLI is. That is what SOAP was. That is what CORBA was, if you were unlucky enough to use it. The mechanism changes. The principle does not.

Programmatic access to resources is not new. It is the foundation of every distributed system ever built. The only thing that changes, decade over decade, is the consumer.

The industry keeps rediscovering the same idea

In 2009, Sun Microsystems submitted WADL to the W3C. It was an XML-based format that described REST services in a machine-readable way: resources, relationships, parameters, methods. That is exactly what an MCP tool definition does. WADL described what a service could do so a machine could figure out how to call it. The W3C never standardized it. Not because the idea was wrong, but because the timing was. There was no consumer sophisticated enough to benefit from it at scale. Before WADL, there was WSDL for SOAP. Before that, IDL for CORBA. MCP is the latest entry. It will not be the last.

Roy Fielding’s original REST dissertation was fundamentally about this same idea. The architecture was designed so that a client could discover what to do next by examining the current representation. You land on a resource, and the resource tells you where its parents are, where its siblings are, what actions you can take, what state transitions are available. The resource graph was navigable. You did not need an out-of-band specification to understand the API because the API told you what it could do, in real time, through its own structure.

The industry took REST, stripped out the hypermedia, ignored the self-describing semantics, and built what Fielding himself called “RPC with pretty URLs.” We turned a semantic architecture into a syntactic one and then spent fifteen years complaining that APIs are hard to discover.

Now MCP shows up and says: what if the service described itself to the consumer? What if the consumer could discover available tools and their schemas dynamically?

That is just REST done right. We had this. We chose not to use it.

The consumer changed, not the concept

The reason MCP matters is not the protocol. It is JSON-RPC with tool definitions and a handshake. Nothing groundbreaking. What changed is the consumer.

For the first time, the primary consumer of a service description is not a human developer. It is a language model. And language models are now sophisticated enough to take a structured tool definition, understand what it does, and invoke it correctly without someone writing integration code.

That is interesting. But it is a shift in the consumer, not in the concept. CLIs have been doing this forever: run --help and you get a structured description of available commands, arguments, types, defaults. APIs have been doing this forever: OpenAPI specs describe endpoints, parameters, request bodies, response schemas. A developer reads the spec and writes the client. An LLM reads the spec and writes the client. Same interface. Different reader.

MCP formalizes this for a specific consumer: AI agents talking to external systems over a standardized transport. That is useful. It is not a revolution.

Protocols do not solve the problems your business actually has

I have spent the last several months talking to operations leaders at some of the largest companies in the world. Financial services firms processing trust documents. Airlines validating flight data. Logistics companies routing shipments. Construction firms digitizing handwritten safety plans. Not one of them has ever asked me what protocol we use.

Every single one of them asks the same question: is this accurate? Can I trust it? Am I going to get fired for deploying this?

That is the question the industry should be obsessing over. Not which protocol wraps the call, but whether the system on the other end actually works when the data is messy, the formats are inconsistent, and the stakes are high.

MCP has real problems that matter to these buyers. It has no enforced authentication. It has no audit trail. It has context bloat issues where dozens of tool definitions consume the model’s attention before a single useful action is taken. The 2026 roadmap is essentially a list of things that need to be fixed before enterprises can take it seriously. Security researchers at RSA this year are demonstrating how MCP vulnerabilities can enable remote code execution and full tenant takeover.

These are not novel problems. They are the same problems every service description protocol has faced. WSDL had security gaps. CORBA had complexity problems. WADL had adoption problems. The pattern is always the same: a new protocol arrives, the industry gets excited, people bolt it onto everything, the security researchers find holes, the enterprises ask about governance.

Meanwhile, the companies that actually need to move data between systems just use APIs. They use webhooks. They use SDKs. They use whatever works. Because the job was never about the protocol. The job is getting data from point A to point B, accurately, reliably, every time. The models by themselves are not going to save anyone. You need the bricks. What those bricks look like matters far more than the protocol that calls them.

What actually matters

When we talk to enterprise buyers at bem, the conversation is never about MCP or REST or any protocol. The conversation is about accuracy: what is the confidence score on each field, how do corrections feed back into the system, can they see the reasoning behind every extraction. It is about deployment: does this run in their VPC, is data encrypted at rest and in transit, does it comply with their egress policies, can they explain this to their InfoSec team on day one. It is about trust: not “trust me, it works,” but “here are the metrics, here is the audit trail, here is what the system got wrong and here is how it learned from it.”

We have been API-first since day one. Adding an MCP server is, frankly, trivial for us. Our API already describes what it does. Our primitives are already composable. Our schemas are already structured. Wrapping that in MCP is texture. It is not transformation.

MCP is a way for Anthropic to compete with the orchestration frameworks of the world. Credit to them, it is working. OpenAI adopted it. Google adopted it. It is becoming a standard. Standards are good. But let us not confuse the standardization of an interface with the invention of a new paradigm.

The paradigm is and always has been: give programs structured access to resources. The interface evolves. The transport evolves. The consumer evolves. The principle is the same.

If your system is well-designed, if your API surface is clean, if your primitives are composable, and if your service can describe itself, then you are already ready for whatever protocol comes next. You were ready for WADL. You were ready for REST. You are ready for MCP. You will be ready for whatever replaces it.

Your buyers are not going to ask you which protocol you support. They are going to ask you if the data is right, if the system is secure, and if it gets better the more they use it. Answer those questions first. The protocols will catch up.

There's a myth circulating in the world of enterprise AI. It's the promise of a magic black box, a single API call that delivers perfect, off-the-shelf accuracy for any document, every time. I’ve tried those systems. They don’t deliver what they promise.

If you're a technical leader, you know this is a fantasy. In the real world of high-stakes, mission-critical operations, "trust me" is not a viable strategy. Enterprise buyers don't want more magic; they want fundamental control. They want a glass box, not a black box.

The Problem with the Black Box

Most AI platforms are designed as a one-way street. You send in your unstructured data, a model does something mysterious, and you get a structured result. But what happens when it's wrong? How do you correct it? How do you ensure the system learns from its mistakes and doesn't repeat them?

For most platforms, the answer is you can't. You're stuck with a static system, forcing your team to build brittle, post-processing logic or, even worse, fall back on manual review. This isn't automation; it's just a more sophisticated way to create more work.

Closing the Loop: The bem Lifecycle

This is the core philosophy behind how we've built bem. We believe that true, production-grade accuracy isn't a static feature you buy; it's a dynamic, continuous process you control. Our platform is designed to provide the full, end-to-end lifecycle for AI.

1. Create a Function: It starts by defining your blueprint. You create a Function that specifies your desired output schema; your definition of "good."

# Create a reusable function for processing invoices
curl -X POST "https://api.bem.ai/v2/functions" \
  -H "x-api-key: <YOUR_BEM_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "functionName": "enterprise-invoice-processor",
    "type": "transform",
    "outputSchema": {
      "type": "object",
      "properties": {
        "vendor_name": { "type": "string" },
        "total_amount": { "type": "number" }
      }
    }
  }'

2. Call the Function: You call your Function with your unstructured data and get an initial structured result.

# Call the function with a new invoice PDF
curl -X POST "https://api.bem.ai/v2/functions/enterprise-invoice-processor/call" \
  -H "x-api-key: <YOUR_BEM_API_KEY>" \
  -F "referenceID=inv_abc_123" \
  -F "file=@/path/to/invoice.pdf"

3. Subscribe & Observe: We provide the "glass box." You create a Subscription to receive results via webhook, and use tools like Function Review for complete transparency into the performance of your functions. You can see accuracy, precision, and recall for every field, giving you a clear, statistical picture of how the system is performing.

# Create a subscription to receive results at your endpoint
curl -X POST "https://api.bem.ai/v1-alpha/subscriptions" \
  -H "x-api-key: <YOUR_BEM_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Invoice Results Subscription",
    "type": "transform",
    "functionName": "enterprise-invoice-processor",
    "webhookURL": "https://api.your-company.com/webhooks/bem/results"
  }'

4. Correct & Fine-Tune: This is the most critical step. We make it easy to give feedback on mistakes. Our API allows you to embed a correction mechanism directly into your own product. When your operators or end-users correct a field, that correction isn't lost; it's a valuable signal that is sent back to our platform via a simple PUT request.

# Send a correction back to bem via the API
curl -X PUT "https://api.bem.ai/v1-beta/transformations" \
  -H "x-api-key: <YOUR_BEM_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "transformations": [
      {
        "transformationID": "tr_2bxoJPNdSD4LgRT4YVC4gt72hlI",
        "correctedJSON": {
          "vendor_name": "Corrected Vendor Name Inc.",
          "total_amount": 150.75
        }
      }
    ]
  }'

This signal automatically triggers fine-tuning jobs. Your users' corrections in production aren't a sign of failure; they are the fuel that drives your unique model to 99%+ accuracy. It's a continuous, self-healing loop.

This is what it means to be an enterprise-ready AI platform. It's not about promising magic. It's about providing the tools, the transparency, and the control to build an AI system you can actually trust with your most critical operations.

Over the last year, we’ve spoken with logistics managers, claims processors, support leads, compliance teams, and others running the actual systems behind enterprise operations. And the message we keep hearing isn’t about LLMs or copilots.

It’s about control.

Operators don’t care if the AI is “smart.” They care if it’s right.
They want systems that are consistent, traceable, and boring in the best way possible.
They don’t want a chatbot. They want a workflow that doesn’t break.

What They’ve Told Us, Again and Again

They’ve told us that automation isn’t useful if it introduces new kinds of chaos.

They’ve told us that they don’t want to replace their teams. They want those teams to stop acting like APIs.

They’ve told us they don’t need another “agent.” They need infrastructure that makes decisions predictable, errors visible, and handoffs clean.

They’ve told us that reliability matters more than novelty, and that “management by exception” is the real unlock: automate everything that’s obvious, and raise a hand only when it’s not.

This isn’t about replacing people. It’s about trusting the system to carry the load so operators can focus on what actually requires judgment.

What We're Trying to Build at bem

We’re not trying to be the smartest AI tool in the room. We’re trying to be the most dependable one.

We built bem to handle the inputs that bog enterprise teams down: emails, PDFs, spreadsheets, multi-step approvals, follow-ups. Then we route that structured data into the systems that already run the business: TMS, ERPs, CRMs, homegrown tools.

It’s not flashy. It just works.

We surface issues when they happen, keep a trail of every decision made, and let users correct the system in-line so the system actually gets better over time, without retraining.

We think of this as an ambient business system. Something that works in the background, doesn’t demand attention, and becomes part of the way the company runs without having to change how people work.

Why We're Writing This

We’re not here to pitch another AI wrapper. We’re writing this because the gap between enterprise need and enterprise tooling is growing, and we’re trying to close it, one workflow at a time.

We’ve learned from the operators who do the hard, manual work to keep their companies running. They’ve shown us what real production pressure looks like, and we’re building bem to relieve it—not by replacing their judgment, but by making space for it.

If this sounds like what you’ve been asking for, we’d love to learn from you too.

Let’s build the infrastructure these teams actually deserve.

It’s 2025, and every structured data vendor is still shouting the same thing: “we’re the most accurate,” “best zero-shot performance,” “production-ready out of the box.” You’ll see it on every landing page and pitch deck, like it’s just a matter of which vendor wins the leaderboard.

At bem, we think that’s a fundamentally broken framing. It treats accuracy like it’s a single, objective number — when in reality, accuracy is always contextual. It depends on your inputs, your schema, your edge cases, your users, and the specific decisions you're making downstream. Accuracy isn't just a model score. It's a reflection of how well a system fits your world.

This obsession with zero-shot performance — how well a model performs on the first try — is seductive. It makes it easy to believe that the hard part of automation has been solved, that models will just know what to do without being taught. But in practice, zero-shot performance is a starting point. It is not the finish line. And treating it like the finish line leads to brittle systems and broken promises.

We’ve seen this same thinking play out in conversations about AGI. The assumption is that, eventually, a superhuman agent will run your business logic for you — navigating edge cases, making judgment calls, handling complexity without ever needing to be taught. But even the most capable agent would need access to your context: your documents, your rules, your systems, your constraints. Otherwise, it's just another hallucination.

This is why we’ve made a different bet at bem. We’re not building a product that claims to be “the most accurate.” We’re building infrastructure that helps you get accurate — quickly, iteratively, and on your terms.

Accuracy at bem doesn’t come from one-shot perfection. It comes from closing the loop.

With bem, every correction you make becomes a training signal. You can turn corrected outputs into golden examples with one click. No external labeling tools, no export-import workflow. Just use the product as intended, and your system gets better in the background.

We let you build golden datasets as part of the normal review process — not as a separate, burdensome task. That means you can track performance, run automated evaluations, and pinpoint where accuracy is degrading or improving over time. We give you versioned workflows, auditable changes, and a full history of how each decision was made.

Even more importantly, bem lets you define what “correct” means. You can use LLMs not just to extract information, but to judge whether an output is valid. Want to check if a document matches a golden reference? Or whether a remittance file includes all the required fields before it hits your ERP? That’s what LLM-as-a-judge enables — and it’s built in.

We call this self-correcting infrastructure. Because every time someone fixes a workflow, the system learns. Every time someone flags a failure, the feedback gets recorded. And every time you run the same flow again, it runs better.

This isn’t a flashy promise. It’s infrastructure that quietly compounds.

So no, we won’t tell you bem is the most accurate platform. That would be meaningless.

What we will tell you is that with a small amount of effort — and the right feedback loops in place — you can get to production-grade, auditable, operator-approved accuracy faster than you thought possible. And your workflows will keep improving over time, without adding headcount or rewriting brittle logic.

Accuracy isn’t a static metric. It’s a system that evolves.

One last thought

There’s something deeper we believe, too: positioning your product around “accuracy” is not just misleading — it’s defeatist.

It’s the kind of posture you take when you’ve given up on system design. You wave around a few benchmark scores and call it “state of the art,” but behind the scenes, it’s all one-off prompt tuning, hand-picked demos, and error-prone edge cases waiting to happen.

The obsession with being “most accurate” traps teams in a Sisyphean loop. Every time the model falls short, you tweak a prompt, update a rule, add a few more examples. Push the boulder a little further up the hill. But the hill never goes away, because the core assumption is wrong: that there is a single, universal definition of accuracy you can optimize for once and be done.

That’s not how real operations work.

In high-stakes industries — freight, fintech, claims, compliance — accuracy is not an aesthetic ideal. It’s a constraint. And it varies based on context, tolerance, and risk. What looks like a rounding error to a model is a regulatory violation to your legal team. What passes in an eval set might break a payment, or misroute a load.

So instead of chasing some mythical peak accuracy, we’ve built bem to focus on something better: adaptation. Accuracy isn’t a fixed point. It’s a process. It’s what happens when the system learns from your users, your data, and your constraints — and gets better every time.

Teams building with LLMs are stuck in a loop:
You write a prompt. It mostly works.
Then a user triggers an edge case. You add a clause to the prompt.
Then someone else hits a slightly different edge case. Another clause.
Another exception. Another fallback.

Eventually, the prompt looks like a legal document.
It’s brittle, unpredictable, and impossible to test end-to-end.

If you're building productized AI — not just prototypes — this is a problem.

Prompts aren’t infrastructure. They’re speculation. And when your business depends on precision — financial operations, logistics, compliance, workflow automation — speculation isn’t good enough.

Why Prompt Patching Breaks Down

Let’s say you’ve deployed an LLM pipeline to extract structured data from freight tenders or webhook payloads.

At first, you’ve got a clean, high-performing prompt. It handles most cases.

Then someone forwards a new variation — a different format, a weird header, a slightly ambiguous field label.
The model guesses wrong. You tweak the prompt. Now the original cases are degraded.
You rewrite it again. Now you’re testing behavior across a dozen scenarios and wondering whether it’s time to fine-tune a model just to parse a PDF.

You’re doing prompt surgery, not product development.

Worse: you’re teaching your team to fight the model, not work with it.

What You Actually Want: A Feedback Loop

Let’s look at a realistic case.

You’re building a freight operations dashboard. Your customers forward you PDF tenders from shippers — sometimes structured, often not. Your product uses bem to extract structured fields so you can feed downstream pricing engines, load boards, or ops workflows.

Here’s the schema you’ve configured in bem for your pipeline:

{
  "type": "object",
  "required": [
    "loadReference",
    "origin",
    "destination",
    "weightTons",
    "pickupDate",
    "deliveryDate",
    "equipmentType"
  ],
  "properties": {
    "loadReference": {
      "type": "string",
      "description": "Customer-assigned ID for this freight load"
    },
    "origin": {
      "type": "string",
      "description": "City/state where the load originates"
    },
    "destination": {
      "type": "string",
      "description": "City/state where the load is delivered"
    },
    "weightTons": {
      "type": "number",
      "description": "Weight of the load in tons"
    },
    "pickupDate": {
      "type": "string",
      "format": "date",
      "description": "Earliest pickup date"
    },
    "deliveryDate": {
      "type": "string",
      "format": "date",
      "description": "Required delivery date"
    },
    "equipmentType": {
      "type": "string",
      "description": "Requested equipment (e.g., '53' dry van')"
    }
  }
}

Let’s say a customer emails in a tender like this:

Please quote the following load: 4/26 pickup in Hutchins, TX to delivery in Denver, CO by 4/29. 42,000 lbs of dry food-grade pallets. Use reference #RDP-3391. Need a 53’ van. No team driver required.

bem extracts this as:

{
  "loadReference": "RDP-3391",
  "origin": "Hutchins, TX",
  "destination": "Denver, CO",
  "weightTons": 42,
  "pickupDate": "2024-04-26",
  "deliveryDate": "2024-04-29",
  "equipmentType": "van"
}

Looks fine — but a human ops analyst catches an issue:
"Van" is too vague. The customer specifically requested 53’ dry van. That's relevant for carrier selection logic.

In traditional prompt engineering, you'd go back into the prompt, add new rules like:

"If 'van' is mentioned and a length is also specified, use the full equipment description."

But then you risk introducing side effects — and you’re still not guaranteed the model will generalize that rule to other variations ("53 ft", "53-ft", "53 foot", etc.).

Instead, with bem, you just send the correction:

PATCH /v1-beta/transformations
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "transformations": [
    {
      "transformationID": "tr_xyz456abc",
      "correctedJSON": {
        "equipmentType": "53’ dry van"
      }
    }
  ]
}

What happens next:

1. The correction is recorded, associated with this exact transformation ID, pipeline, schema, and input content.

2. The underlying model is updated

3. Future transformations of similar data — especially references to vans + specific lengths — will yield the more precise field value without needing another correction or prompt change.

This is learning at the API level — grounded in real product usage.

How Teams Use This in Real Workflows

Here’s what this looks like in practice.

Payments Infrastructure

A product team is classifying inbound webhook payloads from multiple providers. A new bank integration sends test transactions with an undocumented field variation. The model misclassifies them as production events.

A support engineer uses the bem dashboard to patch one case. Future transactions from that bank are classified correctly.

The model evolves with usage — not via new prompts or retraining.

Supply Chain Platforms

A logistics platform uses bem to parse multi-vendor tenders. One customer’s template has a shifted date field — the model reads the deadline instead of the delivery window.

Rather than trying to prompt around every possible vendor variation, the ops team patches the output once via the API. The next file from that customer parses correctly.

The patch creates a form of memory that lives inside the pipeline — not buried in engineering tickets.

B2B SaaS Ticketing

A helpdesk product is using bem for routing intents from inbound support messages. A new client sends product feedback to "support@" with vague language.

The initial output tags it as a bug. A CSM corrects it to “feature request” through the API.

Over time, bem learns what this customer’s team means by “broken” or “not working” — without needing to hard-code their phrasing into the routing logic.

What This Enables

Using PATCH in your feedback loop gives you a few advantages:

• You move from prompt engineering to model feedback.

• You empower non-engineers (support, ops, QA) to improve accuracy.

• You reduce the number of breaking changes introduced by each prompt tweak.

• You let the system learn — which is the whole point of using LLMs in the first place.

This is what scaling looks like. You don’t just ship a static prompt and hope.
You ship a dynamic system that improves every day.

How to Start Using It

If you’re using bem today, the PATCH API is already live:

PATCH /v1-beta/transformations

You pass in:

• transformationID

• the corrected output (correctedJSON)

You can patch directly from internal tools, feedback UIs, or even triggered via human-in-the-loop review steps.

If you’re using our dashboard, corrections are automatically sent through the same flow.

The Bottom Line

If you’re building a product that needs to be right — stop stuffing your prompts with edge-case logic.

That’s not a product strategy. It’s an anxiety loop.

Let your product learn.
Patch bad outputs.
Move forward.

And ship systems that actually get smarter over time.

Freight brokers and 3PLs live in their inboxes. Every quote request, invoice, or rate confirmation arrives via email — often attached as a PDF, Excel, or embedded in the body. Most teams handle this manually. A rep reads the email, copies the data, logs it in a TMS, and maybe replies.

It’s slow, error-prone, and doesn’t scale.

You don’t need a pre-packaged product that tries to guess your workflow.
You need infrastructure that lets you build your own system — exactly how your team works.

With bem, you can build a freight inbox automator that:

• Accepts any email, PDF, XLSX, or attachment

• Classifies it as a quote request or invoice (without regex or manual rules)

• Extracts structured data into your schema

• Notifies the right person or system

• Learns from corrections automatically

Let’s walk through how to build this system — with zero custom model training, just APIs and real infrastructure.

What You’re Building

We'll set up:

1. A quote transformer for requests

2. An invoice transformer for billing docs

3. A router that detects the right doc type

4. Optional notifications or downstream syncs

5. A feedback loop to auto-learn from fixes

Every piece is configurable, modular, and upgradeable — no vendor lock-in, no “feature request” delays. You own it.

Step 1: Define Your Schemas

Before you automate anything, define the output you want. Here are two examples.

Quote Request Schema

{
  "type": "object",
  "required": ["origin", "destination", "pickupDate", "equipmentType", "commodity", "weight", "contact"],
  "properties": {
    "origin": { "type": "string", "description": "Pickup location — city, state, or ZIP" },
    "destination": { "type": "string", "description": "Dropoff location — city, state, or ZIP" },
    "pickupDate": { "type": "string", "format": "date", "description": "Requested pickup date" },
    "equipmentType": { "type": "string", "description": "Requested trailer type (e.g. dry van, reefer)" },
    "commodity": { "type": "string", "description": "Description of freight" },
    "weight": { "type": "number", "description": "Shipment weight in lbs" },
    "contact": {
      "type": "object",
      "required": ["name", "email"],
      "properties": {
        "name": { "type": "string", "description": "Name of the requester" },
        "email": { "type": "string", "format": "email", "description": "Email of the requester" },
        "phone": { "type": "string", "description": "Optional phone number" }
      }
    }
  }
}

Freight Invoice Schema

{
  "type": "object",
  "required": ["invoiceNumber", "loadReference", "carrier", "lineItems", "totalAmount", "dueDate"],
  "properties": {
    "invoiceNumber": { "type": "string", "description": "Invoice identifier" },
    "loadReference": { "type": "string", "description": "Internal reference or load ID" },
    "carrier": {
      "type": "object",
      "required": ["name", "email"],
      "properties": {
        "name": { "type": "string", "description": "Carrier company name" },
        "email": { "type": "string", "format": "email", "description": "Billing contact" }
      }
    },
    "lineItems": {
      "type": "array",
      "description": "List of charges",
      "items": {
        "type": "object",
        "required": ["description", "amount"],
        "properties": {
          "description": { "type": "string", "description": "Charge type (e.g. linehaul, fuel)" },
          "amount": { "type": "number", "description": "Charge amount in USD" }
        }
      }
    },
    "totalAmount": { "type": "number", "description": "Total billed amount" },
    "dueDate": { "type": "string", "format": "date", "description": "Payment due date" }
  }
}

⚙️ Step 2: Create Your Transform Configs

Each schema becomes a transform config in bem. This gives you:

• A dedicated transformer for each doc type

• A unique email to forward files to

• An ID you can use in routing or downstream flows

Create the Quote Transformer

Endpoint: POST /v1-alpha/action-type-configs

{
  "actionType": "transform",
  "name": "Freight Quote Transformer",
  "outputSchemaName": "QuoteRequest",
  "outputSchema": { /* schema from above */ },
  "independentDocumentProcessingEnabled": true,
  "complexTabularTransformEnabled": true
}

Create the Invoice Transformer

Endpoint: POST /v1-alpha/action-type-configs

{
  "actionType": "transform",
  "name": "Freight Invoice Transformer",
  "outputSchemaName": "FreightInvoice",
  "outputSchema": { /* schema from above */ },
  "independentDocumentProcessingEnabled": true,
  "complexTabularTransformEnabled": true
}

You’ll get back two actionTypeConfigIDs and two email addresses — one for each transformer.

🧭 Step 3: Route Automatically (No Regex Needed)

To avoid manually deciding where each doc should go, create a router that uses LLM logic to determine the right destination.

Create the Router

Endpoint: POST /v1-alpha/action-type-configs

{
  "actionType": "route",
  "name": "Freight Intake Router",
  "description": "Detects whether inbound is a quote or invoice",
  "routes": [
    {
      "name": "Quotes",
      "actionTypeConfigID": "<quote_transform_config_id>"
    },
    {
      "name": "Invoices",
      "actionTypeConfigID": "<invoice_transform_config_id>"
    }
  ]
}

No regex. No hand-tuned rules. bem figures out where the doc should go.

You get a single inbox like:

eml_xyz@actions.bem.ai

🛠️ Step 4: (Optional) Trigger Programmatically

Instead of email, you can also use the API directly:

Transform an uploaded file

Endpoint: POST /v1-beta/transformations

{
  "pipelineID": "<quote_or_invoice_config_id>",
  "transformations": [
    {
      "referenceID": "req_001",
      "inputType": "pdf",
      "inputContent": "<base64 file>"
    }
  ]
}

Or send to the router

Endpoint: POST /v1-alpha/actions

{
  "actionType": "route",
  "actionTypeConfigID": "<router_config_id>",
  "actions": [
    {
      "referenceID": "email_123",
      "inputType": "email",
      "inputContent": "<base64 raw email>"
    }
  ]
}

📣 Step 5: Notify or Integrate

Once a document is transformed, you can:

• Send it to a Slack channel

• Notify a rep by email

• Push to your TMS

• Insert into a database

bem gives you all the structured output, and you route it however you want.

This is the power of building it yourself: you own the logic, flow, and UX.

🧠 Step 6: Learn From Corrections (PATCH)

No extractor gets it perfect out of the gate. But with bem, you don’t retrain a model — you just correct and patch.

Let’s say a rep fixes a pickup date:

Submit a correction

Endpoint: PATCH /v1-beta/transformations

{
  "transformations": [
    {
      "transformationID": "tr_abc123",
      "correctedJSON": {
        "pickupDate": "2025-04-23"
      }
    }
  ]
}

That correction gets remembered and used next time.

You’re not building static automation. You’re building infrastructure that learns.

🔄 Why This Matters

Most “AI quoting tools” or invoice parsers give you what they think logistics should look like. But freight is messy. Your formats, fields, contacts, exceptions — they’re unique.

With bem, you don’t need to change how you work. You make the tool work the way you do.

• Want to add PO numbers? Update the schema.

• Want to route invoices differently after 5pm? Add a rule.

• Want to auto-notify reps when BOL is missing? Patch it in.

Invisible automation, fully owned by you. That’s what scales.

🎓 Extra Credit: Add Voice-Native Workflows with Whisper + Cartesia

Want to make your quoting automation feel even more magical? Layer in voice input and output — while reusing the exact same bem pipelines.

Here’s how to do it:

1. Transcribe Audio with Whisper

Use OpenAI’s Whisper API to turn voice memos, phone recordings, or customer voicemails into structured text.

from openai import OpenAI

client = OpenAI()
audio_file = open("/path/to/audio.mp3", "rb")

transcription = client.audio.transcriptions.create(
    model="gpt-4o-transcribe",
    file=audio_file
)

structured_text = transcription.text

Once you’ve got text, just forward it to your existing quote or invoice pipeline in bem — no changes needed. Your schema does the rest.

2. Generate Speech with Cartesia

Want your system to respond conversationally? Use Cartesia’s WebSocket TTS API to turn structured bem outputs into dynamic, natural speech.

Example message over WebSocket:

{
  "model_id": "sonic-2",
  "transcript": "Your quote from Houston to Austin has been generated at $650.",
  "voice": {
    "mode": "id",
    "id": "a0e99841-438c-4a64-b679-ae501e7d6091"
  },
  "language": "en",
  "context_id": "quote-session-123",
  "output_format": {
    "container": "raw",
    "encoding": "pcm_s16le",
    "sample_rate": 8000
  },
  "add_timestamps": true,
  "continue": false
}

Cartesia supports streaming responses, prosody-aware continuation, and high concurrency over a persistent WebSocket — perfect for realtime agents.

3. Close the Loop with bem PATCH

And when users correct something in the voice flow (e.g. “No, I meant Dry Van, not Reefer”), PATCH the corrected output to bem:

PATCH /v1-beta/transformations

PATCH /v1-beta/transformations
{
  "transformations": [
    {
      "transformationID": "tr_xxxx",
      "correctedJSON": {
        "equipmentType": "Dry Van"
      }
    }
  ]
}

You’ve now built a self-healing voice quoting loop — one that learns with every correction.

Why this matters
Email workflows are table stakes.
Voice is next.
And with bem at the center, you don’t need to rebuild anything — just extend what you’ve already built.

This is what infrastructure should feel like:
Composable. Omnichannel. Quietly brilliant.

Let’s Build It

In a few API calls, you just created:

✅ Structured extraction for quotes and invoices
✅ LLM-powered classification without regex
✅ Email-to-JSON pipelines with patchable learning
✅ Full extensibility for notifications and integrations

Want to see this running live?
Drop in a sample doc. We’ll help you build the full flow — your way.

This is what freight ops looks like when you own the system.
Not a product. Not a dashboard. Real infrastructure.

Schedule a demo here.

But what if you could build the exact support system your users need, fully integrated into your UI, Slack workspace, or even an internal dashboard, in two hours?

With bem and a few modern tools (like Supabase and Slack APIs), you can.

This post walks you through a real implementation of an AI-powered, schema-driven support system, from message parsing to triage to ticket assignment, powered by bem’s API.

Let’s build.

The Plan: Invisible Support Infrastructure

We’ll set up a custom support system that handles inbound questions from:

• 📬 Email (e.g. support@yourcompany.com)

• 💬 Slack (e.g. internal #customer-help channel)

• 🧑‍💻 Web app (feedback or help forms)

The system will:

1. Parse inbound support messages (no template needed)

2. Classify by type (bug, feature request, billing issue, etc.)

3. Extract key metadata (e.g. user ID, timestamp, urgency)

4. Hydrate data from your DB (e.g. pull user plan from Supabase)

5. Route to the right person/team

6. Post or email an internal summary with all the context included

7. And optionally: automatically log it in your CRM or issue tracker

Step 1: Define Your Support Schema

Start by defining the structure of a support intake. Here's a sample schema we’ll use in bem:

{
  "type": "object",
  "required": ["type", "description", "userID", "timestamp"],
  "properties": {
    "type": {
      "type": "string",
      "description": "Category of the support request",
      "enum": ["bug", "feature_request", "billing", "other"]
    },
    "description": {
      "type": "string",
      "description": "User's original message or summary of the request"
    },
    "userID": {
      "type": "string",
      "description": "Unique user ID from your internal system"
    },
    "timestamp": {
      "type": "string",
      "format": "date-time",
      "description": "Time the support request was received"
    },
    "urgency": {
      "type": "string",
      "enum": ["low", "medium", "high"],
      "description": "Estimated urgency based on language analysis"
    }
  }
}

Step 2: Create a Pipeline in bem

Use the POST /v1-beta/pipelines endpoint to create a transformation pipeline with this schema.

POST /v1-beta/pipelines

{
  "name": "Support Intake Pipeline",
  "outputSchemaName": "Support Intake",
  "outputSchema": { ... }  // insert the schema from above
}

You’ll receive a pipeline ID and a unique email address like:

eml_xxxxxx@pipeline.bem.ai

Anything you forward to this email gets parsed and transformed in real-time.

Step 3: Set Up Routing Logic

Now let’s build a router to handle classification and dispatch.

Create a router config using POST /v1-alpha/action-type-configs with a few simple rules:

{
  "actionType": "route",
  "name": "Support Router",
  "description": "Routes support tickets by type",
  "routes": [
    {
      "name": "Bug Reports",
      "regex": {
        "patterns": ["crash", "error", "broken", "not working"]
      },
      "actionTypeConfigID": "<pipeline_id_for_bug_support>"
    },
    {
      "name": "Billing",
      "regex": {
        "patterns": ["invoice", "payment", "charge", "receipt"]
      },
      "actionTypeConfigID": "<pipeline_id_for_billing>"
    },
    {
      "name": "General",
      "regex": {
        "patterns": []
      },
      "actionTypeConfigID": "<pipeline_id_for_general_support>"
    }
  ]
}

Connect this router to a shared email inbox or webhook endpoint.

Step 4: Hydrate Data from Supabase (or other data providers)

Now that we’ve extracted userID, we want to enrich the ticket with more info — like plan tier, team size, usage, etc.

Spin up a basic Supabase function:

create function get_user_info(uuid text)
returns table (
  user_id text,
  email text,
  plan text,
  usage jsonb
)
language sql
as $$
  select id, email, plan, usage
  from users
  where id = uuid;
$$;

Call this function from your backend or workflow orchestrator when a new support event is transformed.

There’s a million ways of doing this; optionally, use Chroma or Weaviate to do semantic search over the extracted data to match and hydrate with your own.

We’re releasing Data Hydration as a first-class feature in bem this quarter, so very soon you won’t even need to do this!

Step 5: Notify the Right Team

After hydration, use bem’s email action type to notify your team with enriched support data.

Create an email config:

{
  "actionType": "email",
  "name": "Send to Ops",
  "fromEmail": "support@yourcompany.com",
  "fromName": "Support Bot",
  "toEmail": "ops@yourcompany.com",
  "toName": "Support Team",
  "subject": "New Support Request - {{type}} from {{userID}}",
  "body": "<p>Urgency: {{urgency}}</p><p>{{description}}</p>"
}

Use POST /v1-alpha/actions to trigger the message.

Optional: Log It to Your Internal Tools

Want to push this to:

• Notion?

• Linear?

• Salesforce?

• Zendesk (ironically)?

Just use the transformed output from bem to call their API in your workflow system (like n8n, Make, or plain Node.js).

Business ROI

Why not just use Intercom or Zendesk?

Because:

• Your ops and support teams want precision and context, not another tab

• You want to own your workflows and UI

• Most SaaS support systems cost $10–100 per agent/month, and offer zero extensibility

In 2 Hours You Just Built:

• A real-time, multi-channel intake system

• AI-based triage and routing

• DB-powered ticket enrichment

• Internal team alerts

• Optional CRM logging

All custom, all yours, and all extendable with a single API.

Bonus: Auto-Learn from Corrections

Your team edits a support tag? Just use the PATCH /v1-beta/transformations endpoint to fine-tune future extractions.

You're not building a static system — you're building infrastructure that learns.

Build It Yourself

Want to see this live? Schedule a demo or ping our team. We can help you launch a production-grade support system — customized to your org — in less than a day.

This is what support looks like when it’s invisible, embedded, and built for your product.

When you're moving money, every second counts — and every manual touch is a risk.

In fintech, ops leaders face a paradox: the more they scale, the more brittle internal processes become. Spreadsheets break. SOPs get copied and pasted. And “just forward it to the ops alias” turns into hours of human translation.

This is especially dangerous in workflows like:

• Loan origination

• Underwriting

• Tax and compliance intake

• Treasury and accounting handoffs

Most teams end up building workflows that behave like agents — nudging humans, creating queues, generating ops tickets. That gets expensive fast.

What you need instead is infrastructure that runs invisibly, behind the scenes — taking unstructured documents, classifying them, extracting data, and triggering downstream actions.

That’s what bem was built for.

⚡️ROI in 30 Days: Customers using bem for intake workflows in lending and insurance are eliminating 80–90% of manual data prep work — and in some cases, saving hundreds of hours a week in underwriting and portfolio ops.

Let’s walk through how to do this.

Use Case: Automate Document Intake for Credit Ops

Let’s say you’re running credit ops at a fintech or nonbank lender. You regularly receive:

1. Loan Applications (PDF or email)

2. Revenue Forecasts (Excel or CSV)

3. Balance Sheets (Excel, CSV, or PDF)

Each comes from a different stakeholder — borrowers, brokers, internal teams — and none of it is structured the same way twice.

You want to:

• Automatically classify and route documents

• Extract structured data into a clean JSON schema

• Notify your ops or risk team once complete

This lets you operate at scale without increasing headcount — or asking engineers to build custom pipelines for every document variation.

1. Create Pipelines for Each Document Type

Each document type gets a pipeline that defines:

• The schema for structured output

• Whether you want per-page or per-row processing

• Where to send the results

Endpoint:

POST /v1-beta/pipelines

Here's an example schema for a Loan Application Pipeline

{
  "name": "Loan Application Pipeline",
  "outputSchemaName": "LoanApplication",
  "outputSchema": {
    "type": "object",
    "required": ["applicantInfo", "loanDetails", "submittedAt"],
    "properties": {
      "applicantInfo": {
        "type": "object",
        "properties": {
          "fullName": { "type": "string", "description": "Applicant's full legal name" },
          "email": { "type": "string", "format": "email", "description": "Primary contact email" },
          "phone": { "type": "string", "description": "Phone number" },
          "businessName": { "type": "string", "description": "Name of the applicant's company" }
        }
      },
      "loanDetails": {
        "type": "object",
        "properties": {
          "requestedAmountUSD": { "type": "number", "description": "Loan amount requested in USD" },
          "loanPurpose": { "type": "string", "description": "Purpose of the loan" },
          "termMonths": { "type": "integer", "description": "Loan term in months" }
        }
      },
      "submittedAt": { "type": "string", "format": "date", "description": "Date of submission" }
    }
  }
}

Create similar pipelines for revenue forecasts and balance sheets with fields like forecastStartDate, monthlyRevenue, currentAssets, currentLiabilities, etc.

2. Set Up a Router to Classify Incoming Docs

Instead of relying on humans to manually label or route documents, bem can auto-classify incoming files based on email sender, content patterns, or metadata.

Endpoint:

POST /v1-alpha/action-type-configs

Use actionType: route

{
  "actionType": "route",
  "name": "Credit Intake Router",
  "routes": [
    {
      "name": "loan_applications",
      "origin": {
        "email": {
          "patterns": ["@loanportal.com", "@brokerxyz.com"] /*NEW in Precisioun Router! Optional if you want deterministic matching by pattern*/
        }
      },
      "actionTypeConfigID": "actcfg_loanapp123"
    },
    {
      "name": "revenue_forecasts",
      "origin": {
        "email": {
          "patterns": ["@financials.com"]
        }
      },
      "actionTypeConfigID": "actcfg_revenue456"
    },
    {
      "name": "balance_sheets",
      "origin": {
        "email": {
          "patterns": ["@accountingpartners.com"]
        }
      },
      "actionTypeConfigID": "actcfg_balance789"
    }
  ]
}

This gives you a dedicated bem email address that you can forward files to.

Forward anything there — we'll route it to the right pipeline automatically.

🔁 Strategic Value: Your intake process becomes repeatable and auditable, which reduces compliance risk and improves investor confidence in your data model.

3. Notify Your Team When New Docs Arrive

Once a document is transformed, trigger an email notification to your internal team with the metadata and reference ID.

Endpoint:

POST /v1-alpha/action-type-configs

Use actionType: email

{
  "actionType": "email",
  "name": "Notify Credit Ops",
  "fromEmail": "no-reply@bem.ai",
  "fromName": "Bem Bot",
  "toEmail": "credit-ops@yourcompany.com",
  "toName": "Credit Ops",
  "subject": "New Intake: {{referenceID}}",
  "body": "<p>A new document has been processed for reference ID {{referenceID}}. You can now review the structured data in your dashboard or downstream system.</p>"
}

Chain this email notification by including nextActionTypeConfigID in your pipeline config.

4. Send Documents via API or Email

Option A — API Upload

Endpoint: POST /v1-beta/transformations

{
  "pipelineID": "pl_abc123",
  "transformations": [
    {
      "referenceID": "loan_9821",
      "inputType": "pdf",
      "inputContent": "<base64 file content>"
    }
  ]
}

Option B — Just Email It

Send any file to your router or pipeline address. We'll handle ingestion, routing, transformation, and notifications.

💼 Business Impact: You shorten time-to-decision on every loan file, avoid duplicate intake work, and reduce the burden on your operations team.

5. Monitor and Audit Everything

• View transformation status:
  GET /v1-alpha/tasks

• Inspect processed output:
  GET /v1-alpha/events

• Track and resolve errors:
  GET /v1-beta/transformations/errors

Extra Credit: Embed Fine-Tuning Into Your Existing UI

Once you’ve automated intake and transformation with bem, you’ll likely still encounter edge cases — minor corrections your ops team makes manually in your internal tools or CRM.

Most teams stop there. But with just one more step, you can:

✅ Continuously improve data quality
✅ Reduce manual work over time
✅ Build a feedback loop into your ops product — without the user ever leaving

Here’s how:

Let’s say your credit ops team is reviewing an intake form in your dashboard. They spot that the "requested amount" field was misinterpreted. They correct it directly in your UI.

Instead of treating that as the end of the workflow — use that corrected value to fine-tune bem automatically via our PATCH endpoint.

PATCH /v1-beta/transformations

This endpoint lets you submit a corrected version of the structured output for any specific transformationID.

You don’t have to retrain anything. You don’t need to manage a model. bem handles that behind the scenes — using your correction as signal to improve future results for similar docs.

{
  "transformations": [
    {
      "transformationID": "tr_2bxoJPNdSD4LgRT4YVC4gt72hlI",
      "correctedJSON": {
        "loanDetails": {
          "requestedAmountUSD": 125000
        }
      }
    }
  ]
}

You can even capture a batch of corrections periodically and send them all at once.

Most of our customers get to 99% accuracy with only 10-20 corrections.

The best ops automations are the ones that feel like nothing changed — until they do.

By closing the loop invisibly:

• Your workflows get better the more people use them

• Ops teams don’t need to refile corrections

• Your AI system feels like it’s learning — because it is.

Summary: Fintech Ops that Scale with You

You don’t need a queue of analysts reformatting spreadsheets or parsing PDFs by hand.
You need invisible, composable infrastructure that runs in the background.

bem turns your email inbox or intake folder into structured, actionable data — in minutes, not hours.

Ready to Build?

You don’t need a massive engineering team to automate credit intake.
You just need the right primitives.

📬 Forward a sample doc: hi@bem.ai
💻 Or schedule a demo

Run faster, cleaner, and invisibly, with bem.

The lie is that data is clean, structured, and predictable. That processes follow rules. That every customer behaves the same way. That systems talk to each other neatly, one field at a time.

And because we’ve accepted that lie, we’ve designed our software around it.

Every workflow is hardcoded. Every integration is handcrafted. Every edge case is a ticket. Every exception is someone’s job.

Entire teams are built to catch what the software misses — armies of people stitching together spreadsheets, translating formats, rerunning broken syncs, answering questions the system was supposed to answer. The more you grow, the more it grows with you — not your product, but the shadow org it takes to keep the product working.

This is not a software problem. It’s a systems problem. And it’s time to rethink it entirely.

The mess is not going away

The hard truth is: reality is messy. Inputs are inconsistent. Customers are unpredictable. No two documents look the same. No two systems speak the same language. And no two teams run things exactly alike.

Software has tried to impose structure on this chaos for decades. But it’s always been a brittle kind of structure — based on assumptions that quickly fall out of date.

Most of today’s solutions are attempts to paper over this problem. Agents that click buttons for you. Workflows that guess what you meant. RPA that mimics what a human would do.

But the problem was never that people were too slow. It’s that we’ve asked them to be the bridge between systems that never should have relied on people in the first place.

Software should think like a system, not like a person

At bem, we think about this differently.

We believe the next generation of enterprise software won’t look like better assistants. It will look like better infrastructure.

Not another agent on your screen, but an intelligent layer inside your system — one that sees what’s happening, understands the context, and acts on your behalf.

It won't just process a PDF. It will extract the key data and route it into the right internal system, transformed into your schema, tagged with metadata, matched to existing records, and fully auditable.
It won't just send alerts. It will evaluate real-world events — a new file, a support message, a policy update — and decide what to do with them in real time.
It won't just automate tasks. It will become a substrate for your company’s logic, operating quietly behind the scenes and learning as it goes.

Invisible by default. Observable by design.

This is already happening

We’re seeing this shift today.

Companies are rethinking what internal software should do — not just in back-office workflows, but in the core systems that run their business.
They’re replacing brittle integrations with live transformation. They’re automating document-heavy processes in seconds. They’re routing and interpreting data streams without writing a line of mapping code.

We’ve helped logistics firms ingest EDI and vendor emails and turn them into real-time actions.
We’ve helped fintech companies process invoices, remittances, and statements across formats, routing them automatically into their accounting systems.
We’ve helped healthcare and insurance clients extract structure from claims, forms, and PDFs — reducing hours of human processing down to milliseconds.

All without building a single parser.

This isn’t a future we’re imagining. It’s already here. And it’s just the beginning.

What comes next

Enterprise software is entering a new era.

Not one of screens and dashboards — but one of systems that understand, adapt, and act.
Not one of simulated humans — but one of real machine reasoning, purpose-built for the work behind the scenes.
Not one of reactive tooling — but one of ambient intelligence, wired into your architecture from day one.

That’s what we’re building with bem. A modular platform for structuring, transforming, routing, and automating complex data — across any input, any format, and any scale.
One system. Fully programmable. Fully inspectable. Invisible, until it needs to be seen.

We think this is the future of enterprise software.
If you’re building that future too, we’d love to talk.

Jenny and Erica chat about everything from building products that are accessible for non-technical users, navigating early adopter and user experiences in the new LLM age, and Erica’s experience going through YC and finding a Co-founder.

So, we started with our women’s panel. We brought together incredible panelists who have recently scaled high-growth companies who have not yet reached Series B funding. Folks who have scaled from the ground up and know what it means to say “Oh, I have no idea how to describe my role” because they’re doing.. everything. I was personally shocked at how quickly we filled the 95 person waitlist without much promotion, but was still a bit nervous. Would people relate to this? As someone who has oftentimes felt isolated as a senior generalist in early stage startups, I wasn’t sure. But then a memory of a past manager saying “You seem too calm,” while I was flying around the world to scale the business, kept popping up.

Then, the event was deeply connecting. What an absolute joy to learn from fellow panelists Myoung Kang from MotherDuck (who has scaled so many impressive orgs prior to), Lily Roosevent from HockeyStack, Olivia Baker from Paraform, and our amazing facilitator, a deeply empathetic and curious human being, Kim Chia from Next Legacy Partners.

Folks were honest and raw about so many things- from what they’re currently struggling with (from biking to work to managing balance and what it means to navigate hormone awareness when working 12 hour days). About the notion of "balance" when you're building something from nothing. What it means to stand up to leaders and founders, to take up space and push for things- from cultural to project and business-related.

One of the best parts for me was also watching the event form prior to that day- what it meant to have a group of female leaders come together to plan an event. It felt like a truly democratic process- including down to how we approached topics and who wanted to speak on which. Instead of inflating our nervous systems prior to the talk, we sat in a breath exercise together led by Jenny.

Safety for women and the female experience came up a lot that evening, and is something that I haven’t been able to stop thinking about for a few years now. What does it mean to have enough space to support and grow fellow women in the workplace in an early stage startup while having unlimited amounts of projects and work to do? What does it mean to advocate for them and provide a safety barrier? I know for me personally, I reflect constantly on what it means to be “senior” enough to do more of this- something I’ve failed on as recently as last week.

To be clear, it does feel scary, even for us, which I hate to admit. Will we be taken less seriously? Will we be boxed in as "women who talk about women stuff" rather than technical or business leaders? Will we alienate partners or investors? But the alternative, silence, is what makes me lose the most sleep (which does share space with late night tactical work thoughts).

However, given the event turnout, amazing questions our panelists received from those who attended, and the clear need in our startup industry to fuel more female-forward conversations (as well as my and Jenny’s deep passion for this), we’re excited to announce a few things from our bem team:

• We’re launching our new podcast series, beminist. Our first episode is launching very soon, and we’ll continue our journey of interviewing and highlighting female early stage leaders and builders

• We’re hosting a women in engineering leadership dinner in a month- please contact us directly if you’d like to join. We’d love to have you

• We are hosting another women’s panel in the late spring! This will be announced in early April

Our beminist team is thrilled to offer more space for these conversations. And we’re hiring- if you’re a female engineer or CS lead, please reach out.

In order to produce the next generation of business software, we have to go beyond the inner components and into the packaging of the product and its access pattern. How easy is it to connect to your existing systems? Does a human have to be in the loop?

For decades, businesses have been patching together workflows, hacking inefficiencies with stopgap solutions like spreadsheets, RPA, or agents. These tools were built to survive yesterday’s problems, not scale into tomorrow’s opportunities.

At bem, we’re rethinking how software and businesses coexist. We’re not just building automation tools or band-aid solutions; we’re creating ambient business systems—a generational platform where software doesn’t just run alongside your business but deeply integrates into it.

Here’s how we’re doing it—and why ambient systems are the future.

From Chaos to Clarity: Why Ambient Systems Matter

The back office has long been seen as the “messy middle” of business. Think endless PDFs, emails, ERPs, CRMs, and siloed legacy systems that don’t speak the same language. Traditional tools like RPA or agents tried to tame the chaos but failed to address the root issue: these systems were built to mimic broken processes, not rebuild them.

That’s where bem comes in.

What are ambient business systems?
Ambient systems don’t just react to workflows—they anticipate them, integrate seamlessly, and adapt as your business evolves. They’re invisible yet indispensable. They don’t require dropdowns, custom field mapping, or human workarounds. Instead, they transform every interaction into a seamless, structured process that actually works.

At bem, we believe that businesses shouldn’t be forced to manage complex technical pipelines just to use cutting-edge tools. Unlike other platforms that shift the burden of deploying and maintaining Retrieval-Augmented Generation (RAG) pipelines onto their customers, bem keeps this complexity under the hood.

We integrate RAG, vector storage, and retrieval natively into our platform to power data transformation and enrichment—but this complexity is invisible to our users. Why? Because businesses don’t need to manage infrastructure; they need solutions. Our focus is on delivering outcomes, not technical hurdles.

Generalized, But Earned: Why Specific Use Cases Lead to Universal Platforms

Building a generalized platform is every startup’s dream. But here’s the reality: horizontal platforms aren’t born, they’re earned—customer by customer, use case by use case.

We’ve worked with companies ranging from early-stage startups to Fortune 500 enterprises and governments. Across this spectrum, one truth is clear: customers don’t buy horizontal platforms; they buy solutions to their specific problems.

By deeply engaging with our users’ pain points—whether it’s transforming data dumps into actionable insights, integrating with legacy systems, or automating tedious back-office tasks—we’ve created tailored solutions that will eventually scale across industries.

Our approach:

• Start narrow: Solve specific, high-value problems deeply.

• Think big: Use these solutions to create reusable, scalable components that expand into a generalized platform over time.

Horizontal success is earned through precision, iteration, and listening.

What We’ve Learned: From Experimentation to Transformation

In our first year, we learned that progress isn’t about trying to solve every problem at once—it’s about being pragmatic, focused, and experimental. Here’s what drives us:

1. Deliver Simplicity Through Complexity
   Businesses don’t want to deal with the complexity of deploying infrastructure like RAG pipelines or vector databases. They just want systems that work. At bem, we handle the hard parts—retrieval, enrichment, transformation—so you don’t have to. Our users interact with a clean, simple interface, while we do the heavy lifting under the hood.

2. Build for Specific Use Cases, Generalize Later
   Every enterprise is unique. By solving deeply specific problems first, we’re able to learn, refine, and eventually build reusable solutions. This iterative approach ensures we’re delivering meaningful value, not superficial features.

3. Automation Isn’t Enough—Transformation Is Key
   Automation tools like RPA and “AI agents” often fail because they only patch over inefficiencies. Instead of mimicking human workflows, bem rebuilds them from the ground up—eliminating redundancies and creating systems that are inherently smarter, faster, and more scalable.

4. Customer-Centric Experimentation
   Our platform evolves by learning directly from our users. Whether it’s a startup with a scrappy tech stack or a Fortune 500 company wrangling complex integrations, we partner with our customers to test, refine, and deliver. This collaboration is our superpower.

Beyond Automation: Elevating the Back Office

At its core, bem transforms the back office from a tangle of inefficiencies into a source of value. With bem:

• Data dumps become dashboards.

• Manual workflows become automated pipelines.

• Disconnected systems become seamless integrations.

We don’t just eliminate tedious data entry—we turn it into a competitive advantage. Whether it’s logistics, healthcare, fintech, insurance, or government workflows, bem empowers businesses to operate at their best by enabling entirely new ways of working.

This means moving the back office to customer-facing products. We fundamentally think the back office is dead, and if that’s true, that also means RPA and other puppeteer-based paradigms and agents will become outdated.

The Core Philosophy: Why Ambient Systems Are the Future

Most enterprise software still treats humans like clerks—forcing them to interact with dropdown menus, repetitive forms, and outdated systems. At bem, we’re flipping that script.

We believe that systems should adapt to humans, not the other way around. Ambient systems work for you, invisibly and intuitively. Instead of building bots that mimic human behavior, we’re creating true software abstractions that reimagine workflows entirely.

Our mission is simple:

• Eliminate the need for manual data entry, validation, and communication.

• Create infrastructure that businesses can depend on for decades.

• Build systems that integrate seamlessly into workflows without exposing users to technical complexity.

We don’t think about AI as hype or as “agents” trying to act human. For us, AI is a means to an end—one part of a broader system that redefines how businesses operate.

Why Now, Why Us

The world is at an inflection point. Businesses are drowning in complexity, and the old tools—RPA, agents, and piecemeal automation—are no longer enough.

Advances in AI and machine learning have created a unique opportunity to build something better. At bem, we’re combining decades of experience in automation and data transformation to create a platform that will power the next century of software.

Our unique position:

• From startups to governments: We’ve already proven our ability to solve hard problems across industries, from seed-stage startups to Fortune 500 enterprises and public institutions.

• Data transformation as the wedge: By solving one of the hardest, most universal business problems—data transformation—we’re creating the foundation for broader operational transformation.

• A generational platform: We’re not iterating on old ideas; we’re replacing them. bem is the infrastructure for the software-first economy of the future.

Let’s Build the Future of Business Computing

bem isn’t just a company—it’s a movement. We’re building systems that work in harmony with humans, eliminating inefficiencies, and redefining how software serves businesses.

The back office of today is a patchwork. The back office of the future is ambient, intelligent, and transformational.

If you’re ready to help build that future—with us, as a partner, or as an investor—get in touch.

The next era of software starts here. Let’s make it happen.

Although we’ve been supporting visual documents since we launched our platform, we were most capable in processing english-language documents with clean and well aligned layouts, such as PDF data exports or rendered web pages. However, we found that documents that didn’t have those qualities have been harder to extract data from. Most of this has been related to our internal systems ability to process visual documents.

Why we’ve been working on vision

Ultimately we’ve realized we needed to upgrade our platform with state of the art vision models in order to best serve our customers (and their customers) that require data extraction on a wider range of document types such as:

• Hand written documents

  • Hand writing within forms

  • Physical notes

• Photos of documents

  • Receipt processing

  • Warehouse labels

• Complex layouts

  • Trifold documents

  • Multi-column articles

• Non-english languages

  • Customs forms with multiple languages

  • International receipts

As part of this investigation into our abilities to handle more challenging document types, we created an internal dataset that covered a high variance suite of documents which were representative of the complex needs of our customers across several industries. We used this dataset for accuracy evaluation while testing new internal solutions for visual data extraction, maximizing the performance of our vision system against a diverse array of document types.

How it works

You might be wondering how you can get access to these capabilities, and the answer is our new vision capabilities are available to all new users of bem! Here’s an example of what our new platform capabilities look like in this new update, using a Japanese language receipt as an example.

Given the following document:

We’ll generate the following transformation before and after our vision upgrade.

Before our vision upgrade

{
  "items": [
    {
      "name": "PM 7-11 OHSA4-XR 1P",
      "amount": 460
    },
    {
      "name": "at",
      "amount": 644
    },
    {
      "name": "#5 #",
      "amount": 356
    }
  ],
  "total": 1000,
  "currencyCode": "JPY"
}

After our vision upgrade

{
  "items": [
    {
      "name": "Nissin Cup Noodle Smoky Chili",
      "amount": 184
    },
    {
      "name": "PM Marlboro HS Smooth R 1P",
      "amount": 460
    }
  ],
  "total": 644,
  "currencyCode": "JPY"
}

If you’d like to try out bem, schedule a demo with us below

Schedule a Demo