Why we built Alvys Foundry

Note: Alvys Foundry is the agentic workflow builder inside Alvys TMS. It runs your SOPs on your live freight data, with human approval where you want it.

Freight runs on rules that live in people’s heads. We built Alvys Foundry because the automation tools that could hold those rules were never where the freight data was. 

Every freight operation runs on a set of rules nobody wrote down.

How long a driver waits before you start the detention clock, and which customers get an exception. Which documents have to be on a load before billing will touch it. When a quiet trip becomes a phone call with dispatch. Which carriers you’ll use at 4pm on a Friday and which ones you won’t. These rules are real, they’re specific to your business, and they are the actual operating model — but they live in tribal knowledge, a spreadsheet, a Slack channel, and the judgment of whoever has been there longest.

That’s fine until you try to grow. Then the only way to run more loads with the same rules is to hire more people who know the rules. The operating model doesn’t scale; headcount does.

Why the obvious answer didn’t work‍

Operators have been told for a decade that automation solves this. Most have tried. The results are consistently underwhelming, and the reason is structural rather than a failure of effort.

The rules are contextual, and generic automation is not. Conventional automation is good at rigid, low-judgment tasks: when X happens, do Y. Freight work is rarely that shape. “Start detention” depends on the appointment, the customer’s contract, whether the delay was ours, and what the driver’s HOS clock looks like. Encoding that in a tool that only knows “a webhook fired” means encoding it badly.

The data is in the wrong place. Automation platforms sit outside the system of record and reach in through a connector. That connector is a thing you now own: it drifts, it rate-limits, it lags, and it turns every workflow into an integration project with an owner and a maintenance cost. Teams end up maintaining plumbing rather than improving operations.

Nobody wants to run an AI platform to get an AI outcome. The moment a workflow needs judgment — read this document, classify this email, rank these trips by risk — the shopping list gets long: model access, routing, failover, prompt-injection defense, PII handling, spend limits, an audit trail. That is a platform engineering project, and a brokerage’s engineering capacity is better spent almost anywhere else.

And the ones that survive all that are still unaccountable. A workflow that quietly did the wrong thing 400 times is worse than no workflow. Operators asked reasonable questions we couldn’t answer well with off-the-shelf tools: what exactly did it do, why, and where does a person get to say no?

The bet we made

We could have shipped a connector and a partner listing. Instead we build AI agents inside the inside the TMS, because we think the interesting problem isn’t the canvas — it’s the context.

A traditional transportation management system (TMS) records and coordinates the work. records and coordinates the work. Alvys Foundry helps carry it out.

Three results of building it inside rather than beside:

Your data is the workflow. Foundry runs on live loads, trips, tenders, drivers, carriers, documents, invoices, and settlements. A workflow that needs to know a trip's stop history just knows it. No sync to fall behind. No separate copy of your operation to reconcile.

The 120+ integrations and the native EDI connections to hundreds of shippers are still there. The difference is who owns them. They're ours to keep alive, not yours.

Your rules are the product. Alvys Foundry doesn’t ship a canonical detention process, because there isn’t one. It ships the blocks to express your detention process… including the exceptions, which is where the real work is. A workflow you can’t bend to your customer’s contract is a workflow you’ll stop using by month three.

Every Alvys Foundry action runs through Agent Shield, governed per tenant. A model tier instead of a hardcoded model. A failover chain instead of a single point of failure. Retention rules that fail closed. A spend guard that steps down a tier and says so in the action output instead of quietly degrading on you.

Every Alvys Foundry run records every action's input and output. Human approval goes exactly where you decide it belongs. All of it inside a SOC 2 compliant platform, because the compliance question comes up on day one of every one of these conversations.

What we got wrong first

Two things, worth saying plainly.

We initially over-indexed on the builder. A great canvas is table stakes, not a differentiator. What actually determined whether a workflow made it to production was mundane: could you tell what a failed run did, could you stop it re-alerting on the same trip every hour, and did the search action return data in a shape you could use. Debuggability beats expressiveness.

We underestimated how much the shape of the work matters. The workflows that deliver value are not clever. They are almost all the same five or six shapes — fetch, analyze, branch, alert; loop per record; react to an event; keep a marker so you don’t repeat yourself. We’ve since written those down as patterns and shipped them as prebuild agent templates, because handing someone a blank canvas and wishing them luck is not enablement.

Where we think this goes

Some honest labeling: what follows is direction, not a roadmap commitment.

The trajectory we believe in is from workflows to agents, gated by trust rather than by capability. The technical ability to let software handle a longer, more consequential chain of work is arriving faster than most operations’ willingness to allow it — correctly, in our view. Nobody should hand over carrier selection to a system whose reasoning they can’t inspect.

So the work we think matters is the boring half: evaluations that tell you whether a workflow is actually deciding well, not just running; approval gates you can tighten and loosen as evidence accumulates; and a control view where an ops leader can see what their agents did all week and why. Autonomy earned per workflow, with evidence, is worth more than autonomy claimed in a keynote.

The other direction is compression of the distance between an SOP and a running workflow. Today someone reads the SOP and builds the workflow. We’re exploring how much of that translation the system can propose while a human still approves it — which is a genuinely hard problem, and one we’d rather ship late than ship wrong.

The one-line version. Why carriers and brokers need Alvys’ AI Agents. 

Freight carriers and brokers don’t need another tool to automate clicks. They need their operating model to run with their rules, on their data, under their control.

That’s what we’re building.

Frequently asked questions

What is Alvys Foundry?

Alvys Foundry is the agentic workflow builder inside the Alvys TMS. It runs your SOPs on live freight data, with 20+ prebuilt agent templates and the option to build your own.

Does Alvys Foundry require a separate integration to the TMS?

No. Alvys Foundry is built inside the Alvys TMS, so it reads live loads, trips, tenders, drivers, carriers, documents, and invoices directly. There is no connector to build and no sync that can fall behind.

Can Alvys Foundry workflows be customized to our detention rules?

Yes. Alvys Foundry ships the blocks to express your detention process, exceptions included, instead of a canonical one every customer has to accept. If your clock starts differently for one customer's contract, the workflow bends to that.

Who approves what an Alvys Foundry agent does?

You do. Approval gates go wherever you decide they belong, and every Alvys Foundry run records each action's input and output so an ops leader can see what happened and why.